Re: filtering HTTPS

Amos Jeffries wrote:
> On 14.03.2012 15:16, Henrik Nordström wrote:
>> ons 2012-03-14 klockan 14:18 +1300 skrev Amos Jeffries:
>>
>>> huh? it says exactly what protocol the tunnel is intended to contain
>>> (switch to).
>>
>> On GET/OPTIONS yes, but only for the transport, not tunnel.
>>
>> You can use Upgrade on CONNECT as well if you want. But it's for the
>> client<->proxy only and says nothing about the contents of the tunnel
>> requested by CONNECT.
>>
>> CONNECT www.example.com:80 HTTP/1.1
>> Upgrade: TLS/1.0
>> Connection: Upgrade
>>
>> instructs the proxy that the client wishes to have the client<->proxy
>> connection wrapped in TLS/1.0. If the proxy agrees it sends a HTTP/1.1
>> 101 Switching Protol response and any further communication from that
>> point is wrapped in SSL client<->proxy, without changing the tunnel (it
>> may still be SSH, IMAP, SMTP or whatever).
>
> Telling us a bump is needed to find out more.
>
> The *inverse* of this is what I'm saying is significant. When TLS is
> *not* present its clearly not going to be something we can ssl-bump.
> Therefore skip the bumping and don't interfere.

The existence of SSL/TLS does not suffice for making a conclusion.
The tunnel can be used for SSL+SMTP, SSL+XMPP, SSL+anything.

I think Squid should do the following in the sslBump handler:

- Open socket. If error, close socket to the browser.
- possibly: go to the filters indicating the start of a CONNECT, a filter may decide to BLOCK just based on the endpoint address.
- Initiate SSL/TLS handshake, if error, signal filters (preferably indicating there is no SSL/TLS)
   If the filter says "PASS", reopen a socket to have a clean tunnel
- If the SSL/TLS handshake is ok, do the certificate checking. If error, send an erroneous certificate to the browser to give the end user a good idea of what is going on.
- Verify that the server speaks SSL+HTTP, if not signal filters (preferably indicating there is SSL/TLS but no HTTP)
- If the endpoint speaks SSL+HTTP, go to the filters, indicating a succesful CONNECT to an SSL+HTTP endpoint.

>>> For a bit of perspective: We could take a GET with Upgrade:, send it
>>> unchanged to a peer and treat the resulting TCP connection as an
>>> Upgraded tunnel over which native X traffic happens. No different to
>>> handling a CONNECT today.
>>
>> Clients may only send Upgrade together with Connection: Upgrade as it's
>> a hop-by-hop directive, so any proxying of the directive would
>> technically be a protocol violation.
>
> We are asking an HTTP peer to Upgrade its hop. We have not sent
> acceptance to the client, and will relay the peers reject/accept. No
> violation there. We just loose control of a HTTP connection by trying is
> all.
>
> Amos
>
>
Received on Wed Mar 14 2012 - 12:55:16 MDT