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

attached is what I get when I block https to youtube without MitM

I'm sorry but even a dialog box that said "proxy denied connection", and 
even just printed the status line would be more useful than this:

"The webpage at https://www.youtube.com/ might be temporarily down or it 
may have moved permanently to a new web address"

this is PURE FICTION.

It serves only to confuse users, and cause them to look in the wrong 
places for the problem.

A savvy user may see the "ERR_TUNNEL_CONNECTION_FAILED" and realise it's 
something to do with a proxy.

but the connection didn't fail, it was refused.

This is just a source of pain for all users.  There's no excuse to be 
lying to browser users like this.

Adrien


------ Original Message ------
From: "Mike Bishop" <Michael.Bishop@microsoft.com>
To: "Adrien de Croy" <adrien@qbik.com>; "Ryan Hamilton" 
<rch@google.com>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 16/02/2017 9:52:14 AM
Subject: RE: The future of forward proxy servers in an http/2 over TLS 
world

>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:adrien@qbik.com]
>Sent: Wednesday, February 15, 2017 12:40 PM
>To: Ryan Hamilton <rch@google.com>; ietf-http-wg@w3.org
>Subject: 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.
>>>>
>>
>>