Re: SSL/TLS everywhere fail

On Fri, Dec 04, 2015 at 06:42:03PM -0700, Alex Rousskov wrote:
> 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.

Some developers were moderately interested, because if we overcome the
UI issues it's obviously a saner situation for everyone, starting with
users. Clearly I'd like to be able to say "my webmail access are made
over TLS terminated at the proxy and my bank and paypal are done in a
tunnel through the proxy which whitelists them as considered safe".

> > 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:
> https://github.com/bagder/curl/pull/305

Ah interesting! Thanks for the pointer!

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

I think that even if this WG is not working on UIs there are all the
relevant participants here who can propose or reject proposals for some
methods. We proposed some principles in the past but did not make progress
and there were other subjects to focus on. There's no doubt that the product
must be shipped as secure by default so that the user has to do something to
lower the security level. And even in this case it will be needed to support
exceptions to either mode.

The very first goal I was seeking with TLS proxies was to protect
authentication credentials. And immediately it appeared as the cleaner
way to at last let the user decide what content may be analysed and
what content may not be.

Willy

Received on Saturday, 5 December 2015 02:01:54 UTC