<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA1 <br>
     <br>
    I think,<br>
    <br>
    non-HTTP/HTTPS security issues is never ever Squid function.<br>
    <br>
    Squid is not all-in-one-security-solution. It's only HTTP proxy.<br>
    <br>
    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.<br>
    <br>
    AFAIK, primitive Cisco extended ACL + tcpiputils.com and simple
    sniffer can make miracles.<br>
    <br>
    Following I offer to retirn to the Earth and limit our functionality
    as I said before. Just HTTP/HTTPS over 443 port.<br>
    <br>
    I understand that exists wonderful and overall solutions like
    ufdbGuard. But we talk not about it.<br>
    <br>
    05.01.2015 17:51, Marcus Kool пишет:<br>
    <span style="white-space: pre;">> Much of the discussion so far
      has been about bumping traffic on port 443,<br>
      > bumping SSL-encapsulated HTTP traffic and not bumping
      (allowing)<br>
      > other traffic.  Since port 443 is used for many protocols, it
      is in many<br>
      > cases dangerous to allow non-bumpable traffic: SSH tunnels
      using port 443<br>
      > are common, so are VPNs.  Do you know a security officer who
      does not want<br>
      > to block an SSH tunnel, or an app that can share corporate
      documents<br>
      > on public websites?  If there is not more attention to these
      kinds of<br>
      > applications that use port 443 to circumvent corporate
      firewalls,<br>
      > Squid will be doomed to be used only in environments where
      the priority<br>
      > for security is low to non-existent.  Just type "punching
      holes in corporate<br>
      > firewalls" or "ssh tunnel proxy" in Google to see how easy it
      is to use an<br>
      > SSH tunnel.<br>
      ><br>
      > I am the author of ufdbGuard, a filter for Squid and besides
      filtering<br>
      > based on URLs, ufdbGuard also probes port 443 to see what
      kind of traffic<br>
      > the server is expecting.  By using probes, ufdbGuard can
      detect SSH tunnels,<br>
      > popular chat protocols, etc. but it is not a 100% guaranteed
      solution<br>
      > because ufdbGuard cannot not see the traffic that flows
      through the proxy,<br>
      > i.e. there is not yet an interface for this type of traffic
      inspection.<br>
      ><br>
      > Marcus<br>
      ><br>
      ><br>
      > On 01/05/2015 07:59 AM, Eliezer Croitoru wrote:<br>
      > Hey Yuri,<br>
      ><br>
      > Indeed there are other *NIX systems and for each and every
      one of them<br>
      > there is a solution in need.<br>
      ><br>
      > SSL Pinned destinations cannot be identified automatically
      since the<br>
      > are pinned inside a software and the certificate will not
      show<br>
      > anything about that.<br>
      > The basic tests we can do are:<br>
      > - The host is using ssl or tls or not at all(based on the
      selective<br>
      > answer of the service)<br>
      > -<br>
      > - If the connection is using tls\ssl then inspect the
      components of<br>
      > the certificate(such as rootCA validation against the local
      machine<br>
      > certificates DB)<br>
      ><br>
      > Depend on the goal of the certificate validation the decision
      will be<br>
      > made to either allow the connection "uninspected" or to
      "bump" it as<br>
      > is without any smart identification.<br>
      ><br>
      > If indeed there is a database<br>
      > sqlite3\mysql\postgres\redis\memcached\others it can be used
      in the<br>
      > iptables level.<br>
      > Also a point in this DB and this cache is that it will be
      persistent<br>
      > so what so ever the *NIX system is there is an option once
      the IP +<br>
      > port was tagged as non-bump-able it is better be in the
      FIREWALL level<br>
      > override better then squid external_acl.<br>
      > Reason: If the kernel does what it needs to do then squid
      should not<br>
      > touch the packets.<br>
      > It's not always right but it's a point in the issue.<br>
      > I still do not know how to work with NFQUEUE and I am sure
      that there<br>
      > is an option to make a fast decision and if not then let the<br>
      > connection be BUMPED.<br>
      ><br>
      > I have written a small golang script that can check couple
      things<br>
      > about the ssl session at:<br>
      > <a class="moz-txt-link-freetext" href="http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go">http://www1.ngtech.co.il/squid/ssl_helpers/ssl_validator.go</a><br>
      ><br>
      > Besides this helper there is another script which do couple
      things in<br>
      > another level.<br>
      ><br>
      > ##########<br>
      > If any thing will be decided for squid internals it will be
      after a<br>
      > proof of concept that we can implement together.<br>
      > Can we take this thread to storm and put on the table a proof
      of<br>
      > concept logic for ssl inspection\bumping and bypassing?<br>
      ><br>
      > Eliezer<br>
      ><br>
      > On 01/05/2015 10:40 AM, Yuri Voinov wrote:<br>
      > >>> Sounds good,<br>
      > >>><br>
      > >>> but server world is not end on Linux. ;)<br>
      > >>><br>
      > >>> Now exists another *NIX systems. And will exists
      further.<br>
      > >>><br>
      > >>> Also. I have an idea, gents.<br>
      > >>><br>
      > >>> Do we can easy and quickly detect SSL Pinned
      destinations? And<br>
      > >>> remember it, for example, in database?<br>
      > >>><br>
      > >>> In another words - both problems is similar.
      Either non-HTTPS<br>
      > >>> traffic over 443 port, or pinned certs.<br>
      > >>><br>
      > >>> Can we detect both of them automatically and add
      to exclude list?<br>
      > >>><br>
      > >>> WBR, Yuri<br>
      ><br>
      >> _______________________________________________<br>
      >> squid-users mailing list<br>
      >> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      >> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      >><br>
      > _______________________________________________<br>
      > squid-users mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBAgAGBQJUqoe7AAoJENNXIZxhPexGJqoH/2byMvv1s1Qgk5Wh1EwB8ai/
<br>
    B6wsw6IvHitGvkrS77OEkEtZYjMsbTEv7XEpZuBvsylIGTr8Zp9amyjcTLOG/A+2
<br>
    3L4FwlC2QHj6plf4owN5i3ydKwByZP4qRw97Ydg6rsXM/UpD3ePZl9tWf4TVZDLf
<br>
    4bv7EErFYN4tnVjsDEKYWfwfbvJkbbOwt/v1LHTyhyhJiP4Q+bQW3iqGfsgyaMbW
<br>
    3frxeuZrjNikH3OC9eqFI+bY41n4IUkz5pKdItqzTCEDAo6NghJJrACeG+jQA2+Q
<br>
    3WotAv33ErIe7DiRKgBmSRGbzfe5Cbgd4LVn5BUUbsDboRaVb6NrIu2kwzE03OY=
<br>
    =nev9
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>