On Wed, Feb 15, 2017 at 3:11 PM, Adrien de Croy <adrien@qbik.com> wrote: > > > yes, that's what caused the problem in the first place, and until we trust > the proxy I don't think we'll move on from there. > > Which means the connection to the proxy needs to be TLS. > > 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? > > Adrien > (firefox hat) we trust the error came from the proxy - but we don't trust displaying custom text it in the usual way without significant UI around it as we would normal content - content comes from the origin and in https is authenticated as coming from the origin. While we will authenticate a proxy (and its a good feature!), we aren't trusting it to generate https:// content - just transport it over a CONNECT tunnel so if there is an an error message that isn't generated by the origin, we would need a different way to display it. I'm not saying that's impossible - I'm just saying it doesn't exist. we would need new UI for messages clearly from an authenticated (I'm not sure I would use the word trusted) third party. The alternative, as you mention, is to double down on two-party communication - that imperils the traditional role of proxy. Some people feel that's a better model and some disagree. That fight continues in what people choose to implement.
Received on Wednesday, 15 February 2017 20:23:09 UTC