- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 03 Jan 2012 13:36:48 +1300
- To: igor.faynberg@alcatel-lucent.com
- CC: Torsten Lodderstedt <torsten@lodderstedt.net>, ietf-http-wg@w3.org, oauth@ietf.org
On 1/2/2012 7:07 AM, Amos Jeffries wrote: >> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: >> ... >>> >>> general note: I do not understand why caching proxies should impose >>> a problem in case TLS is used (end2end). Could you please explain? >> >> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP >> hops). Proxies which decrypt TLS and provide responses out of cache >> are already deployed in many places. Mostly in the form of >> reverse-proxies, but corporate decryption proxies are also on the >> increase. >> >> AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: > I am at a loss here; granted, it is a gray area... Does it mean that > RFC 2817 has not been implemented properly? > From RFC 2817: " 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. " The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. > To make it simple: At the client, I establish a session key with the > server, and then use it for confidentiality. How is this key known to > any proxy? "the server" is a proxy. AYJ
Received on Tuesday, 3 January 2012 01:19:49 UTC