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

["Adrien de Croy" <[e-mail]>]

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" <[e-mail]>
To: "Mike Bishop" <[e-mail]>; "Ryan Hamilton" 
<[e-mail]>; "[e-mail]" <[e-mail]>
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" <[e-mail]>
>To: "Adrien de Croy" <[e-mail]>; "Ryan Hamilton" 
><[e-mail]>; "[e-mail]" <[e-mail]>
>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:[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]>
>>
>>To: "Adrien de Croy" <[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]> 
>>>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]>
>>>>
>>>>To: "Adrien de Croy" <[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]> 
>>>>>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.
>>>>>
>>>
>>>