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

Re: SSL/TLS everywhere fail

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 4 Dec 2015 18:42:03 -0700
Cc: Willy Tarreau <w@1wt.eu>
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <566240EB.8020600@measurement-factory.com>
On 12/04/2015 06:09 PM, Willy Tarreau wrote:
> On Fri, Dec 04, 2015 at 02:15:46PM -0700, Alex Rousskov wrote:
>> 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). 

Yes, this is a challenging UI problem. It will take a talented and
_interested_ browser developer to solve it, so it may take many years
before such solutions cover enough traffic.

> 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.

Yes, I know. We have added https:// proxy support to Curl and had to
jump through a few hoops, including OpenSSL bugs:

> 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.

Since IETF does not do UI (AFAIK), the only thing we can do is to
publish an RFC that says an HTTP client configured to use a trusted
HTTPS proxy MAY, with user permission, send all https:// URIs to that
proxy instead of using CONNECTs. And then translate that into H2 speak.

And then wait 10-15 years for browsers to start supporting it :-).

Received on Saturday, 5 December 2015 01:42:38 UTC

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