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

Edge is about the same without the button and a more millenial-friendly 
translation of the IE text.

FF on the other hand states the actual problem, that the proxy refused 
to make the connection.

I guess I'll be recommending FF from now on to my customers with this 
problem.

Adrien


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

>the one for IE is even worse.  It offers a connection troubleshooter 
>button.
>
>After exhorting the user to try 3 useless pointless tasks that will not 
>help at all.
>
>What a time waster!
>
>Adrien
>
>------ Original Message ------
>From: "Adrien de Croy" <adrien@qbik.com>
>To: "Mike Bishop" <Michael.Bishop@microsoft.com>; "Ryan Hamilton" 
><rch@google.com>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>Sent: 16/02/2017 10:11:53 AM
>Subject: 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.
>>>>>>
>>>>
>>>>