Re: The future of forward proxy servers in an http/2 over TLS world

------ Original Message ------
From: "Ryan Hamilton" <rch@google.com>
To: "Adrien de Croy" <adrien@qbik.com>
Sent: 16/02/2017 9:26:37 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>I'm not sure what a "Trusted proxy" means in this context. If the proxy 
>can mint certificates that are trusted by the browser, then the proxy 
>can terminate TLS connections at the proxy and impersonate the origin. 
>This is a supported use-case in Chrome (and other browsers).
minting certs is a MitM function.  I wasn't referring to that.

But if the proxy can mint certs that are trusted by the browser, the 
question is how is that.  The proxy would need to be using a signing 
cert that is trusted by the browser, and how did it get installed in the 
browser?

In any case as per my original post, MitM is getting squeezed out by 
HSTS, PKP etc.  Instead of promoting an arms-race between client vendors 
and proxy vendors (e.g. our current next step is to attack HSTS and PKP 
to enable us to continue to display block pages that don't cause our 
customers headaches) how about we work together to allow decent secure 
blocking of requests?

Blocking is a completely legitimate need in corporate networks and 
others.

Currently the balance of power has swung to the user, whether that's a 
child surfing where he/she shouldn't or whoever.

Blocking has become less precise, and the way it's going will have to be 
done at the IP or TCP level.  The lower the level you block at, the 
worse the user experience, and the more time wasted in organisations 
chasing phantoms mis-reported by browsers.

Does h2 even support a proxy?  CONNECT is HTTP/1

Adrien

>
>
>On Wed, Feb 15, 2017 at 12:23 PM, Adrien de Croy <adrien@qbik.com> 
>wrote:
>>
>>how did they trust the proxy?
>>
>>I'm suggesting trusted proxy, which means the proxy would need to use 
>>a cert trusted by the client.
>>
>>I'd go further and say we need to do better than proxy auto-detect as 
>>well - it needs to be secured.
>>
>>Adrien
>>
>>
>>------ Original Message ------
>>From: "Ryan Hamilton" <rch@google.com>
>>To: "Adrien de Croy" <adrien@qbik.com>
>>Sent: 16/02/2017 9:22:06 AM
>>Subject: Re: The future of forward proxy servers in an http/2 over TLS 
>>world
>>
>>>On Wed, Feb 15, 2017 at 12:11 PM, Adrien de Croy <adrien@qbik.com> 
>>>wrote:
>>>>We already support this with WinGate and I've verified it with 
>>>>Chrome and Firefox.  In that case couldn't the client trust an error 
>>>>response body from CONNECT?
>>>
>>>​We used to do this in Chrome, but removed it because of the 
>>>potential for phishing. Here's just on example
>>>
>>>Imagine that at user has their browser configured to do proxy auto 
>>>discovery. They walk into a cafe and join a wireless network which 
>>>sends their traffic to a malicious proxy. The user types 
>>>https://mail.example.com/, and is presented with a CONNECT error page 
>>>whose contents look exactly like the actual mail.example.com login 
>>>page to which they dutifully type their username and password.
>