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

exactly.

This was what used to happen prior to 2008 or so.

I think basically the browser just needs to stop trying to hide the 
existence of the proxy from the user.

It needs to be clear the response comes from the proxy not the origin 
server.  I could imagine many ways to achieve this.

Even if there were a (centrally administerable) setting in the browser 
to show these or not, with limits on what it could contain, I'd have 
something to go back to my users with.

Adrien

------ Original Message ------
From: "Tom Bergan" <tombergan@chromium.org>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Kari Hurtta" <hurtta-ietf@elmme-mailer.org>; "HTTP working group 
mailing list" <ietf-http-wg@w3.org>; "Ryan Hamilton" <rch@google.com>
Sent: 17/02/2017 7:50:35 PM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>Ok, thanks, it took me a while to parse what you're talking about. You 
>started by talking about TLS, HSTS, and PKP, and I thought you were 
>talking about the challenges of MITM-ing a connection. Moving blocking 
>logic to a side-channel removes the need to MITM.
>
>Now it sounds like you just want to show custom error messages for 
>rejected CONNECT requests. Ryan can speak to Chrome's policy on this 
>better than me.
>
>[sorry for the dup, replied from the wrong address]
>
>On Thu, Feb 16, 2017 at 9:05 PM, Adrien de Croy <adrien@qbik.com> 
>wrote:
>>
>>I fail to see what a side-channel would even add in this case.
>>
>>There's already communication between the client and the proxy.  It's 
>>the CONNECT request message and its response.
>>
>>It was the abandonment of that response in non-200 cases that led to 
>>the need to deploy MitM.
>>
>>It was deemed easier to just do this, rather than code a browser to 
>>not follow a 30x response to CONNECT or to not display working forms 
>>from 403 response bodies to CONNECT requests.
>>
>>The phishing argument gets wheeled out every time, but it doesn't hold 
>>water for a second.
>>
>>A browser displaying a form and performing its action does so by the 
>>browser's choice.  To do so based on content in a 403 response to 
>>CONNECT is unjustifiable.  Displaying the original URI in the 
>>navigation bar is completely wrong as well.
>>
>>But instead of just saying "hang on a minute, this is a 403 from a 
>>CONNECT" and displaying in some safe mode, clearing the URL, no that 
>>was too much work, we'll just throw the whole thing away, who cares 
>>about users, they can run around in circles doing the suggestions we 
>>tell them which we know are false.
>>
>>Make sure the URL is valid
>>search for it
>>Check your connectivity
>>
>>I've had people who have spent hours checking cables, routers, ringing 
>>site operators etc to finally get to us and when we tell them what is 
>>going on, they are very far from impressed.
>>
>>But now I have 2 answers, MitM or Firefox.
>>
>>Cheers
>>
>>
>>------ Original Message ------
>>From: "Kari Hurtta" <hurtta-ietf@elmme-mailer.org>
>>To: "HTTP working group mailing list" <ietf-http-wg@w3.org>
>>Cc: "Adrien de Croy" <adrien@qbik.com>; "Kari Hurtta" 
>><hurtta-ietf@elmme-mailer.org>; "Ryan Hamilton" <rch@google.com>; 
>>"HTTP working group mailing list" <ietf-http-wg@w3.org>
>>Sent: 17/02/2017 5:52:45 PM
>>Subject: Re: The future of forward proxy servers in an http/2 over TLS 
>>world
>>
>>>>  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?
>>>
>>>If proxy CA certificate can be installed to browser, then it is also 
>>>possible
>>>to install browser plugin to browser.
>>>
>>>That browser plugin can implement some kind sidechannel.
>>>
>>>But different browsers and OSes, cpus need all diffrent plugin.
>>>Proxy CA certificate format does not change here.
>>>
>>>I see why that direction is selected.
>>>
>>>And network border (or proxy) need some way to verify plugin
>>>is active and sidechannel is in use on many use scenario.
>>>Otherwise may be even disabled accidentally on browser update.
>>>
>>>Hmm. One radical sidechannel is what tells symmectric encryption
>>>key of TLS connection. I guess that this is not acceible for browser
>>>plugin either. In that case proxy can verify that it have symmectric
>>>encryption key for TLS connection.
>>>
>>>
>>>Internet Content Adaptation Protocol (ICAP, RFC 3507)
>>>can perhaps act as standardised sidechannel protocol,
>>>but that does not look like practical and is is
>>>not implemneted by browsers. Basically that means
>>>that content is moved several times. And also
>>>network border (or proxy) can not verify that sidechannel
>>>is on use.
>>>
>>>/ Kari Hurtta
>>>
>>>
>>>
>>
>>
>