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

last image...

this is what you get if you turn on https inspection (MitM).

So you can guess what our customers do.

How this is a win for the internet is beyond me, but it's what we're 
forced to do.

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:20:25 AM
Subject: 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.
>>>>>>>
>>>>>
>>>>>