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

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

Received on Friday, 17 February 2017 05:06:05 UTC