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

[Tom Bergan <[e-mail]>]

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 <[e-mail]> 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" <[e-mail]>
> To: "HTTP working group mailing list" <[e-mail]>
> Cc: "Adrien de Croy" <[e-mail]>; "Kari Hurtta" <
> [e-mail]>; "Ryan Hamilton" <[e-mail]>; "HTTP
> working group mailing list" <[e-mail]>
> 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
>>
>>
>>
>>
>
>