<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>
    We haven't filtering non_HTTP over port-443. Just recognize and
    pass.<br>
    <br>
    05.01.2015 21:15, Marcus Kool пишет:<br>
    <span style="white-space: pre;">><br>
      ><br>
      > On 01/05/2015 12:38 PM, Douglas Davenport wrote:<br>
      >> Marcus, not to distract from the very important main
      points being discussed here but I have to question your last line:<br>
      >> "i.e. there is not yet an interface for this type of
      traffic inspection."<br>
      >><br>
      >> Is that not the whole point of Squid's ICAP interface and
      HTTPS bumping? Or do you just mean that ufdbguard doesn't utilize
      that yet. If so you might want to consider adding that
      functionality...<br>
      ><br>
      > ICAP does<br>
      >    HTTP filtering based on URL and HTTP content<br>
      >    port-443 filtering based on FQDN  (ICAP server only
      receives "CONNECT <FQDN>:443")<br>
      >    port-443 filtering based on HTTP content _if_ Squid uses
      sslbump<br>
      ><br>
      > ICAP does _not_<br>
      >    port-443 filtering for non-HTTP protocols<br>
      ><br>
      > ICAP was designed for HTTP-based content modification.<br>
      > There is no industry standard for filtering non-HTTP data.<br>
      > I have discussed this subject twice with the Squid
      development team<br>
      > but there is currently no sponsor to implement a new protocol
      to filter<br>
      > non-HTTP data in Squid.<br>
      ><br>
      > Marcus<br>
      ><br>
      ><br>
      >><br>
      >><br>
      >> On Mon, Jan 5, 2015 at 9:10 AM, Marcus Kool
      <<a class="moz-txt-link-abbreviated" href="mailto:marcus.kool@urlfilterdb.com">marcus.kool@urlfilterdb.com</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:marcus.kool@urlfilterdb.com"><mailto:marcus.kool@urlfilterdb.com></a>> wrote:<br>
      >><br>
      >><br>
      >><br>
      >>     On 01/05/2015 11:11 AM, Yuri Voinov wrote:<br>
      >><br>
      >><br>
      > And also:<br>
      ><br>
      > don't forget about bogus homebrew internet-bankings. Which is
      uses bogus SSL-certs with bogus GOST realisations. And bogus
      Java-based clients. All of them also uses 443 port. And often
      HTTPS with<br>
      > homebrew bogus features.<br>
      ><br>
      > We don't know, how to bump it.<br>
      ><br>
      > What about it? Pass-through? Pass-through.<br>
      ><br>
      > This is clean exclusion.<br>
      ><br>
      > So don't worry about SSH/Tor. To block them we will be use
      another solutions. DPI. And not always technical. Revoke
      administrative rights from clients is basics of security, like
      physical<br>
      > access to<br>
      > infrastructure. If they can't install Tor/SSH - why we can
      worry about this traffic?<br>
      ><br>
      > We have (and can solve) two simple problems. HTTP over 443
      port. And SSL Pinning. That's all, folks.<br>
      ><br>
      ><br>
      > >>     It is clear what *you* want.<br>
      > >>     You prefer  Squid + HTTP filter + Cisco/DPI +
      tcputils + sniffer + manual maintenance of ACLs/exclude list<br>
      ><br>
      ><br>
      ><br>
      > 05.01.2015 17:51, Marcus Kool пишет:<br>
      ><br>
      >     Much of the discussion so far  has been about bumping
      traffic on port 443,<br>
      ><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>
      <a class="moz-txt-link-rfc2396E" 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>
      <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto: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>
      <a class="moz-txt-link-rfc2396E" 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>
      <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto: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>
      <a class="moz-txt-link-rfc2396E" href="http://lists.squid-cache.org/listinfo/squid-users"><http://lists.squid-cache.org/listinfo/squid-users></a><br>
      ><br>
      >><br>
      >><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>
      <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto: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>
      <a class="moz-txt-link-rfc2396E" 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>
      <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto: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>
      <a class="moz-txt-link-rfc2396E" href="http://lists.squid-cache.org/listinfo/squid-users"><http://lists.squid-cache.org/listinfo/squid-users></a><br>
      >><br>
      >></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBAgAGBQJUqqtYAAoJENNXIZxhPexG/ycH/2TMGOJIxoRgX4UjYzqDN2MX
<br>
    Fv69+gewkPAGwVU5WTOPujW40OykH+mmKP3bFqGHWPhmcNZCkLhSILGPzjeHCeGY
<br>
    6vliHNgrNtrOW3wkVJcwlmKGs+LAR+52L9lXSOW/xZtYY3ExRQESvfQp2egTvedi
<br>
    iYGto9m6o5DRXRB0381eUB0BxdJusPTCYdHbN0bl3Ae/YdAs7IGNdBYJtPtjRf0n
<br>
    5G1NaYBF3Av/4jI6/pCewEbY7jdJa/GJPqP7SNjvVQKAj0wieu9fEWSQTt8VbClw
<br>
    IjLjYNCxXv/hhrwaX8cKFNQk6ICIS5r/HcJQvpM+q9YQ0LU9dDT6c9SUV3O6bAw=
<br>
    =l9by
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>