RE: SSL/TLS everywhere fail

Ability to authenticate and encrypt HTTP traffic towards Proxy is great.
This should make it much harder to wiretap and monitor traffic on a web client to Proxy link by an attacker.

If Proxies received data as HTTPS they must use HTTPS on the upstream link (to an upstream proxy or origin server) to deter attacks on that link as well.

Mobile APN profile currently does not have 'use https' option.
If 3GPP would add that as an option that would improve user security.
I realize that this is out of scope for this working group.

Proxy itself, as long as it is legitimate and trusted by a web user, does not fall into wiretapping or Pervasive Monitoring definitions:
BCP 188 states that PM applies to "behavior that subverts the intent of communicating parties without the agreement of those parties.".
Since end user configured the proxy (as part of APN or WiFi profile) and therefore he did consent for the traffic to traverse through proxy.

Users however did not specify the extend of actions they authorized the proxy for.
Some Mobile Network Operators provide portals where users can specify what functionality
they want Operator Proxy to perform and from what functionality they want to opt out.
Some do not provide portals but if a user calls customer support and requests opt out they would enter the information into subscriber database.
There may be other ways how users authorize Proxy to perform parental controls, caching, web and video optimization, etc. 
Operator Proxies follow these user instructions.

Perhaps this WG could design an HTTP extension which would provide semantics on how this kind of authorization
could be done in HTTP itself rather than through an external portal?
When users attach a Proxy could send a list of functionality it provides and users could select which functionality they allow and which they want to opt out from?
Browsers could provide 'proxy indicator' with would allow users to modify the settings at a later time.
If the user requests Proxy to filter bad stuff (malware, phishing, viruses, pornography, violence) before it reaches its device, 
the protocol extension should give Proxy means to decode but not modify the content -- a decryption key would be shared with Proxy but not message integrity/signature key.
If the user requests Proxy to modify the content -- e.g. adapt video quality level based on current congestion level and bandwidth available in the radio network --
Proxy would get both decryption and integrity keys.
Does that sound like something completely off or perhaps a reasonable future HTTP/TLS extension?

Piotr

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Saturday, December 05, 2015 5:39 AM
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Alex Rousskov <rousskov@measurement-factory.com>; HTTP Working Group <ietf-http-wg@w3.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: SSL/TLS everywhere fail

Hi Pat!

On Sat, Dec 05, 2015 at 11:23:53AM +0100, Patrick McManus wrote:
> Firefox "proxy over https" support was released in October 2014; 
> Chrome beat us to it. I've heard microsoft banter on the topic, but 
> I'm not sure if it is currently available. In both browsers you can do 
> h1/h2/spdy over that link - including mux'd connect tunnels within one 
> h2/spdy session to the proxy with proxies that support h2/spdy This 
> has some really nice TCP side-effects when done over poor links. Still 
> waiting for several proxies to pick up that feature. (that game works 
> both ways :)..)

Really cool! I know a number of people who will be quite interested, I'll pass the message. I know some places where it will make a stop to the awful cookie redirect dance. And this is a situation where there's no fear for breaking non-browser devices since they already don't work :-)

> UI is done via PAC (which can be done without an external PAC file 
> fwiw) in both browsers.

Yes I remember William explaining this for Chrome a while ago. That seems reasonable for environments where https proxies matter.

> I think we will probably add a checkbox for it when we update that 
> configuration screen (For which I have a different reason to schedule 
> work anyhow, so this can piggyback).
> 
> But of course, this just authenticates the proxy and secures the 
> transport to it -

It's already critically important to "unbreak" many places playing the redirect dance.

> it does not trust the proxy with https data split browser style. I 
> find it hard to imagine doing so would be in the best interest of our 
> users. Third parties that would like to be part of that conversation 
> will assert opportunity cost or just authority and disagree with my opinion.
> cest la vie.

That's fine and it *must not* trust that proxy by default. User expects the connection to be terminated by the browser (or the local malware but let's not make things complicated) and we'll need to work on the "GET https://" ideas to see how we can offer that control to the user to be allowed to go out in controlled environments.

Willy

Received on Monday, 7 December 2015 18:00:12 UTC