W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Yet another trusted proxy suggestion

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 26 Nov 2013 08:55:35 -0500
Message-ID: <CAOdDvNp5HiMZ6H_C9C1kmw_8VcWwva=4Je8qD3CE7OrEdzKGrw@mail.gmail.com>
To: Yoav Nir <synp71@live.com>
Cc: Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
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.

IMO and somewhat separately - the notion of a1953.d.cdn.net being able to
present some kind of assertion (outside of the TLS handshake) provably
signed by download.adobe.com that says the cdn host is allowed to serve
content for 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> 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. The proxy
>>> tries to connect, and then either of two things happens:
>>>  1. a1953.d.cdn.net has a certificate for download.adobe.com - that is
>>> what we do today.
>>>  2. a1953.d.cdn.net has a certificate for 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 is a trusted proxy for 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
>
>
Received on Tuesday, 26 November 2013 13:56:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC