|
-----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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users >> > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > 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----- |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
