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

Re: Yet another trusted proxy suggestion

From: Yoav Nir <synp71@live.com>
Date: Tue, 26 Nov 2013 14:49:31 +0200
Message-ID: <BLU0-SMTP192E15FDAB132D2DC053EFDB1EC0@phx.gbl>
To: Roland Zink <roland@zinks.de>, ietf-http-wg@w3.org
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.


Received on Tuesday, 26 November 2013 12:50:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC