Re: Yet another trusted proxy suggestion

in my view a "trusted proxy" should allow to tunnel TLS exactly as a proxy in HTTP1.1
why should behave in a different way in 2.0?


On Nov 26, 2013, at 3:55 PM, Patrick McManus <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:

Yes, please be explicit on this point - CONNECT currently gives end to end assurances through a proxy and your proposal turns that on its head. To ensure clarity I would appreciate it if you didn't reuse CONNECT when proposing Explicit MITM proxy semantics.

While we're at it, imo, E-MITM is a much clearer term than the trusted proxy euphemism being used.

no it is not MITM is usually used to talk about a security attack.
Here we are talking of an intermediary that explicit signal the presence and that disclosure somehow whatever it is going to do.
Actually it should be only possible for the proxy to do what the UA agree with it

/Sal


IMO and somewhat separately - the notion of a1953.d.cdn.net<http://a1953.d.cdn.net/> being able to present some kind of assertion (outside of the TLS handshake) provably signed by download.adobe.com<http://download.adobe.com/> that says the cdn host is allowed to serve content for download.adobe.com<http://download.adobe.com/> is something we ought to explore. I wouldn't wrap that up in the client side proxy discussions though.



On Tue, Nov 26, 2013 at 7:49 AM, Yoav Nir <synp71@live.com<mailto:synp71@live.com>> wrote:
On 26/11/13 2:34 PM, Roland Zink wrote:
Step #3
=======
The browser sends a CONNECT command to the proxy (maybe that has to be enhanced as well?) to connect to https://download.adobe.com<https://download.adobe.com/>. The proxy tries to connect, and then either of two things happens:
 1. a1953.d.cdn.net<http://a1953.d.cdn.net/> has a certificate for download.adobe.com<http://download.adobe.com/> - that is what we do today.
 2. a1953.d.cdn.net<http://a1953.d.cdn.net/> has a certificate for a1953.d.cdn.net<http://a1953.d.cdn.net/>, and issues a "mandatory proxy" alert with its name.
In the former case, things will work as today. In the latter case, I'm not sure how the proxy (or browser for that matter) can know that a1953.d.cdn.net<http://a1953.d.cdn.net/> is a trusted proxy for download.adobe.com<http://download.adobe.com/>. Having the private key is a good indication, but I think we want to get away from that.
Either way, the connection is established

Is the Connect like in HTTP/1.1 the CONNECT method opening a TLS connection from the client to the CDN (TCP from proxy to CDN)? Or is this only opening a TLS connection from the proxy to the CDN? I'm assuming it is the latter

I don't think a "trusted proxy" would allow us to just tunnel TLS, so it's a different thing. It tells the proxy to open the connection onwards. Could be a new method or a special frame.

Yoav