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: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.

so at this point you have a browser rendering a usable form from a 403 
body, and processing it?

this seems like just a really stupid thing for a browser to do, rather 
than a protocol problem.

It's not like the 403 status was hidden from the client.

The original FF bug reported by Adam Barth which kicked this all off 
involved a browser following a 302 response to a CONNECT method.

Maybe browsers shouldn't follow 302 responses to CONNECT.

But deciding to block bodies chucked the baby out with the bath water, 
and we have been answering tech support tickets on it ever since and 
telling people the only work-around is MitM.

Adrien