[squid-users] Squid 3 SSL bump: Google drive application could not connect

Mon Jan 5 12:46:51 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think,

non-HTTP/HTTPS security issues is never ever Squid function.

Squid is not all-in-one-security-solution. It's only HTTP proxy.

For others security breches (i.e SSH tunnels, various browser
tunnel-related plugins, Tor etc., ) we have another tools. Cisco NBAR
proticol discovery, other DPI solution.

AFAIK, primitive Cisco extended ACL + tcpiputils.com and simple sniffer
can make miracles.

Following I offer to retirn to the Earth and limit our functionality as
I said before. Just HTTP/HTTPS over 443 port.

I understand that exists wonderful and overall solutions like ufdbGuard.
But we talk not about it.

05.01.2015 17:51, Marcus Kool пишет:
> Much of the discussion so far has been about bumping traffic on port 443,
> bumping SSL-encapsulated HTTP traffic and not bumping (allowing)
> other traffic.  Since port 443 is used for many protocols, it is in many
> cases dangerous to allow non-bumpable traffic: SSH tunnels using port 443
> are common, so are VPNs.  Do you know a security officer who does not want
> to block an SSH tunnel, or an app that can share corporate documents
> on public websites?  If there is not more attention to these kinds of
> applications that use port 443 to circumvent corporate firewalls,
> Squid will be doomed to be used only in environments where the priority
> for security is low to non-existent.  Just type "punching holes in
corporate
> firewalls" or "ssh tunnel proxy" in Google to see how easy it is to use an
> SSH tunnel.
>
> I am the author of ufdbGuard, a filter for Squid and besides filtering
> based on URLs, ufdbGuard also probes port 443 to see what kind of traffic
> the server is expecting.  By using probes, ufdbGuard can detect SSH
tunnels,
> popular chat protocols, etc. but it is not a 100% guaranteed solution
> because ufdbGuard cannot not see the traffic that flows through the proxy,
> i.e. there is not yet an interface for this type of traffic inspection.
>
> Marcus
>
>
> On 01/05/2015 07:59 AM, Eliezer Croitoru wrote:
> Hey Yuri,
>
> Indeed there are other *NIX systems and for each and every one of them
> there is a solution in need.
>
> SSL Pinned destinations cannot be identified automatically since the
> are pinned inside a software and the certificate will not show
> anything about that.
> The basic tests we can do are:
> - The host is using ssl or tls or not at all(based on the selective
> answer of the service)
> -
> - If the connection is using tls\ssl then inspect the components of
> the certificate(such as rootCA validation against the local machine
> certificates DB)
>
> Depend on the goal of the certificate validation the decision will be
> made to either allow the connection "uninspected" or to "bump" it as
> is without any smart identification.
>
> If indeed there is a database
> sqlite3\mysql\postgres\redis\memcached\others it can be used in the
> iptables level.
> Also a point in this DB and this cache is that it will be persistent
> so what so ever the *NIX system is there is an option once the IP +
> port was tagged as non-bump-able it is better be in the FIREWALL level
> override better then squid external_acl.
> Reason: If the kernel does what it needs to do then squid should not
> touch the packets.
> It's not always right but it's a point in the issue.
> I still do not know how to work with NFQUEUE and I am sure that there
> is an option to make a fast decision and if not then let the
> connection be BUMPED.
>
> I have written a small golang script that can check couple things
> about the ssl session at:
> http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go
>
> Besides this helper there is another script which do couple things in
> another level.
>
> ##########
> If any thing will be decided for squid internals it will be after a
> proof of concept that we can implement together.
> Can we take this thread to storm and put on the table a proof of
> concept logic for ssl inspection\bumping and bypassing?
>
> Eliezer
>
> On 01/05/2015 10:40 AM, Yuri Voinov wrote:
> >>> Sounds good,
> >>>
> >>> but server world is not end on Linux. ;)
> >>>
> >>> Now exists another *NIX systems. And will exists further.
> >>>
> >>> Also. I have an idea, gents.
> >>>
> >>> Do we can easy and quickly detect SSL Pinned destinations? And
> >>> remember it, for example, in database?
> >>>
> >>> In another words - both problems is similar. Either non-HTTPS
> >>> traffic over 443 port, or pinned certs.
> >>>
> >>> Can we detect both of them automatically and add to exclude list?
> >>>
> >>> WBR, Yuri
>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUqoe7AAoJENNXIZxhPexGJqoH/2byMvv1s1Qgk5Wh1EwB8ai/
B6wsw6IvHitGvkrS77OEkEtZYjMsbTEv7XEpZuBvsylIGTr8Zp9amyjcTLOG/A+2
3L4FwlC2QHj6plf4owN5i3ydKwByZP4qRw97Ydg6rsXM/UpD3ePZl9tWf4TVZDLf
4bv7EErFYN4tnVjsDEKYWfwfbvJkbbOwt/v1LHTyhyhJiP4Q+bQW3iqGfsgyaMbW
3frxeuZrjNikH3OC9eqFI+bY41n4IUkz5pKdItqzTCEDAo6NghJJrACeG+jQA2+Q
3WotAv33ErIe7DiRKgBmSRGbzfe5Cbgd4LVn5BUUbsDboRaVb6NrIu2kwzE03OY=
=nev9
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150105/90bc952a/attachment.html>