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

[Mike Bishop <[e-mail]>]

No, CONNECT is HTTP, full stop.  The use of that method is defined for HTTP/1.1, HTTP/2, and even HTTP/QUIC.  You can speak HTTP/2 to a proxy if you want – you get a multiplexed connection to the proxy, and what the proxy uses on the back-end is opaque to you.

I’m somewhat sympathetic to the complaint that we’ve doubled down on two-party communication when there are legitimate use cases for having a third party with some level of access to the traffic.  The problem is that these use cases run the gamut as to how much access they need, and they’re equally applicable to illegitimate cases.  (Or rather, cases *I* perceive as illegitimate, since that’s a policy judgement and not a technical one.)

Groups such as IEEE’s Encrypted Traffic Inspection working group are trying to build something like this, but they make me nervous.  You can’t build a mechanism into a protocol that restricts it to virtuous uses – see RFC3751 for a good example here.  The best that can be achieved is to surface to the user an authenticated identity of who’s spying on their traffic – but we all know the outcome of user dialogs asking “would you like to agree to some technical gobbledygook, or would you like to not see your dancing kittens?”

From: Adrien de Croy [mailto:[e-mail]]
Sent: Wednesday, February 15, 2017 12:40 PM
To: Ryan Hamilton <[e-mail]>; [e-mail]
Subject: Re: The future of forward proxy servers in an http/2 over TLS world



------ Original Message ------
From: "Ryan Hamilton" <[e-mail]<mailto:[e-mail]>>
To: "Adrien de Croy" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]>>
To: "Adrien de Croy" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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<http://mail.example.com> login page to which they dutifully type their username and password.