Re: Talking HTTPS to proxies

Hi Adrien,

On Fri, Apr 15, 2011 at 11:47:08AM +1200, Adrien de Croy wrote:
> 
> Hi
> 
> I think it's a good idea, but there could be some gotchas, especially 
> with proxies that intercept SSL connections on port 443 and do MITM so 
> they can scan https traffic.
> 
> In fact scanning https traffic is a big problem for companies, since 
> more malware uses https to download more malware to avoid scanning.
> 
> I'm wondering if it wouldn't be a good time to start getting browsers to 
> off-load the actual TLS function to the proxy.

Agreed. Anyway, in many cases, the proxies have to do other tricks such
as presenting fake certificates to browsers in order to be able to scan
HTTPS traffic, so where this is deployed, the proxy is already the one
terminating the SSL for both sides, except the client is not aware of it
at all.

> e.g. if a browser is using a proxy, and wants to go to 
> https://secure.qbik.com, currently they do
> 
> CONNECT secure.qbik.com:443 HTTP/1.1
> etc
> 
> then (maybe) negotiate their own SSL/TLS connection, then send (maybe) 
> an HTTP request.  I say maybe, because in many cases, the client can do 
> whatever they like with the connection.
> 
> If instead the client sent
> 
> GET https://secure.qbik.com HTTP/1.1
> etc
> 
> then several benefits come about:
> 
> a) the proxy knows (and can enforce) that the client is using http over 
> SSL/TLS.  In fact the proxy implements it.
> b) the proxy doesn't need to use dest port in policy for CONNECT, since 
> CONNECT can be blocked off completely, and https://site:port syntax can 
> be used instead.
> c) the proxy can do cert validation for the client
> d) the proxy can scan the data, cache it etc.
> 
> It would be trivially simple for a proxy to support https:// syntax, as 
> well as a client to use it.  It would need to become an optional setting 
> in the client though, whether to use a tunnel, or https:// request 
> semantics.

I agree with your proposal, and in fact once the SSL/TLS tunnel is possible
between the client and the proxy, it seems really obvious that it should
work like this ! The client would then be aware of the offloading. It could
even be possible for the proxy to inform the client via a header that the
server's cert had issues (eg: expired, etc...) and the company's security
policy could decide whether the proxy accepts such connections and reports
the issue or blocks them.

> tunneling is a security quagmire, it would be great to be able to lock 
> it down.  At the moment, there aren't many options, since the proxy only 
> sees server:port.  CONNECT is abused by many applications.

I'm well aware of that, I'm abusing it on a daily basis to access my mail
over SSH, which is made possible via all the horrors I described in the
first mail :-)

Regards,
Willy

Received on Friday, 15 April 2011 04:43:57 UTC