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.

On Thu, Feb 16, 2017 at 9:05 PM, Adrien de Croy <adrien@qbik.com <mailto: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 <mailto:hurtta-ietf@elmme-mailer.org>>
To: "HTTP working group mailing list" <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>
Cc: "Adrien de Croy" <adrien@qbik.com <mailto:adrien@qbik.com>>; "Kari Hurtta" <hurtta-ietf@elmme-mailer.org <mailto:hurtta-ietf@elmme-mailer.org>>; "Ryan Hamilton" <rch@google.com <mailto:rch@google.com>>; "HTTP working group mailing list" <ietf-http-wg@w3.org <mailto: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