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

also, as was the argument made way back.

a client that can't tell the difference between a 403 and a 200 status 
response to a connect, and therefore can't display the body in a way 
appropriate to this should just be fixed.

It's entirely possible to render the body on a 403 response, knowing 
it's a 403 response, in a way that can't expose the user to any 
phishing, for example

a) disable and/or strip any hyperlinks
b) suppress any jscript or embedded resources (CSS, JS) except images, 
which are vetted also
c) show it in a different frame with diagonal black and yellow

This would have solved the problem from the start.

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.