W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: SSL/TLS everywhere fail

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 5 Dec 2015 02:09:16 +0100
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Ted Hardie <ted.ietf@gmail.com>
Message-ID: <20151205010916.GE23210@1wt.eu>
On Fri, Dec 04, 2015 at 02:15:46PM -0700, Alex Rousskov wrote:
> > This allows you to use cryptographic
> > confirmation that you are talking to the appropriate proxy, since it can
> > provide you such an assertion over that hop (which it cannot do the same
> > if acting as an interception proxy).  
> No, secure communication with forward proxies is currently not supported
> by many popular browsers. They can tunnel HTTPS through a forward HTTP
> proxy, but they cannot be configured to encrypt their connection to the
> forward proxy using TLS.
> However, let's ignore that huge problem as well. Let's assume I trust my
> unsecure connection to the forward proxy.
> Now, I enter "google.com" in my address bar and ... I get an error
> because Google redirects me to a secure site and the forward proxy
> cannot inspect my HTTPS communication with Google, blocking me despite
> my consent to be inspected.
> I have consented. I have set up an explicit proxy. The proxy plays by
> the rules. And yet nothing works! At this point, my employer is forced
> to attack my HTTPS traffic even though neither they nor me want to
> resort to those dirty tricks.

This is what ought to be covered by what we used to call the "GET https://"
a few years ago, ie : ask a trusted proxy to be the TLS endpoint. This would
get rid of a lot of legitimate MiTM devices and make them more suspicious
again. From what I remember from the conversations, the main difficulty to
address is how to let the user *clearly* know that his connection is going
to be seen by the proxy or is truly secure (CONNECT). The other one (less
important for the long term, might be a technical issue for the short term)
was that doing TLS inside a CONNECT tunnel over a TLS proxy connection was
not the easiest thing to do, probably in part because SSL libs APIs are even
harder to use between chained buffers than they are between a buffer and a
file descriptor. While this last point can justify some delay in deployment,
it should not be a showstopper at all. I find the first issue (user experience)
a real one that deserves some discussion though.

Received on Saturday, 5 December 2015 01:09:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC