W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 03 Jan 2012 13:36:48 +1300
Message-ID: <4F024DA0.7080707@treenet.co.nz>
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.

Received on Tuesday, 3 January 2012 01:19:49 UTC

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