Re: filtering HTTPS

And if both sides is monitored for traffic then detection do not need to rely on timeout. If any message is seen from server or if something that do not look like ssl hello is seen from client then enter tunnel mode.

There is one but still, non-http protocols over ssl/tls, not just CONNECT but actual ssl/tls. Those need ssl/tls tunnel mode where application protocol is tunneled between client and server ssl connection. And maybe a dynamic ssl-bump blacklist.

A sslbump whitelist is probably desired as well, skipping ssl/tls verification if it's already known the server is an https server.

----- Ursprungsmeddelande -----
> There is one option more.
>
> On CONNECT first (after host based filters) verify that connection
> works, but nothing more.
>
> Then wait for client hello ssl packet, if no hello packet is seen within
> a not too long timeout or if some non-ssl/tls traffic is seen enter
> tunnel mode.
>
> If a ssl hello packet is seen enter ssl-bump.
>
>
> ----- Ursprungsmeddelande -----
> > Sorry for the lengthy message. I could not address the issue with less
> > words.
> >
> > Filtering HTTPS is more difficult than filtering HTTPS because CONNECT
> > is used by various applications (browsers, Chat applications, tunnels,
> > VPNs etc). So CONNECT is used for 'regular' HTTPS sites who use
> > SSL+HTTP and sites that use other protocols, e.g. SSL+XMPP, Skype,
> > SSH, and many others.
> >
> > To filter CONNECT with Squid one can use ICAP or the URL rewritor.
> > I have written and published ufdbGuard, a free URL rewritor, and
> > I am developing a new ICAP-based filter which is not yet published.
> > The problem with filtering CONNECT/HTTPS exists for both filtering
> > solutions and differ only in a few details.
> >
> > The Squid administrator can choose to use the sslBump feature.
> > Although sslBump enables filters to look at content and see complete
> > URLs there is still a major issue: applications that use CONNECT to
> > access sites that do not use SSL+HTTP (https).
> >
> > Issue 1: one cannot block CONNECT in an elegant way. I.e. a CONNECT
> > to an undesired site cannot be redirected or anything since the
> > application (possibly browser) want do a SSL handshake and it it fails
> > it displays the 'vague error' "cannot connect to site www.example.com"
> > which is indeed vague for an end user who usually only understands
> > messages like "you are not authorised to go to www.example.com".
> >
> > For true SSL+HTTP (https) sites, issue 1 can be resolved by *not*
> > blocking the CONNECT and wait for the next "GET
> > https://www.example.com/index.html" and block/redirect this object.
> > Lets call this a 'postponed SSL+HTTP block'. But for sites which do
> > not use SSL+HTTP there is not a good solution since Squid and the URL
> > redirector only see a CONNECT and never see a GET/HEAD/POST.
> >
> > Issue 2: Skype does not work any more with sslBump. SSH tunnels, VPNs
> > and other chat applications also stop working with sslBump since the
> > sslBump feature does its SSL certificate checking and if this fails,
> > the CONNECT fails. Using the options 'sslproxy_cert_error allow all'
> > and 'sslproxy_flags DONT_VERIFY_PEER' is not considered useful since
> > thay are truely very unsafe and I recommend never to use them.
> >
> > More background information:
> > The URL redirector ufdbGuard has a feature to probe HTTPS connections.
> > It does a SSL-handshake if this works it is followed by "GET /
> > HTTP/1.0" If the SSL-handshake does not work it probes for SSH, Skype
> > and other chat protocols to find out where the the application
> > CONNECTs to. ufdbGuard can block CONNECT to IP addresses but make
> > exceptions for the CONNECTs which are used by allowed chat protocols.
> > SSH and VPNs are blocked by ufdbGuard if the administrator has
> > configured to block proxies.
> >
> > HTTPS is used more and more. Even Google uses it for their search
> > engine. It is necessary to have a safe HTTPS proxy and content
> > filtering in an absolutely safe and efficient way.
> >
> > Proposal:
> > To have a good combination of web proxy and content filtering
> > combination I propose the following:
> > A) Squid's behaviour is modified for sslBump: after an unsuccessful SSL
> > handshake, the CONNECT does not fail any more by default.   This is to
> > ensure that Skype et al. remains functional.
> > B) Squid gets a new option to define its behaviour in case the SSL
> > handshake fails. The options could be called sslBumpForNoneSSL with
> > values prohibitNoneSSL (terminate connection), passNoneSSL (always
> > allow), filterNoneSSL (default value - let ICAP or URL rewritor
> > decide). C) Squid notifies the URL rewritor and ICAP server about the
> > result of the SSL handshake. This is to optimise the filters and not
> > do things twice. Web servers do no like probes and may temporarily
> > block sites that use Squid if they receive too many probes, so the
> > least number of probes the better. I.e. the line sent to the URL
> > redirector is extended with a new flag like
> > "SSLhandshake=(verified|noSSL)". This should not break existing URL
> > redirectors since it already has the variable length urlgroup and most
> > URL redirectors will consider the new flag part of the urlgroup.
> > Probably a few URL redirectors need a minor modification. For ICAP
> > Squid could send a new header called X-Squid-SSLhandshakeResult. D)
> > squid.conf.documented, wiki and other documentation is updated that
> > 'sslproxy_flags DONT_VERIFY_PEER' and 'sslproxy_cert_error allow all'
> > are unsafe and not recommended. E) the option 'squid-uses-ssl-bump' is
> > introduced to ufdbGuard. If set to 'yes' it will not verify the use of
> > proper SSL certificates. If Squid can send the new flag SSLhandshake
> > (URL redirector) or X-Squid-SSLhandshakeResult (ICAP server), the URL
> > redirector and ICAP servers can be optimised further.
> >
> > Marcus Kool
Received on Tue Mar 13 2012 - 14:44:20 MDT