Very good to have a clear sequence! Many thanks for all the work
explaining this to me.
Maybe my misunderstanding can be corrected by considering observations
1) and 2) and answering question 3) in-line:
On 1/3/2012 8:30 PM, Amos Jeffries wrote:
... Here is a transaction sequence for that bank:
client 1 to proxy:
GET /?oauth_token=FOO HTTP/1.1
Host: bank.example.com
1): If this transaction is done over TLS, then this specific proxy is
the ONLY entity in the chain that knows the token at the moment, and
since it is in the same domain as the server, we must assume its fidelity..
proxy to server:
GET /?oauth_token=FOO HTTP/1.1
Host: bank.example.com
2) Now the server knows it, too.
(server verifies the token "FOO" is valid for client 1 through the
proxy)
bank server to proxy:
HTTP/1.1 200 OK
stuff
proxy to client 1:
HTTP/1.1 200 OK
stuff
.. some time passes. The token "FOO" expires, gets replaced by token
"FOO-2".
client 1 to proxy:
GET /?oauth_token=FOO-2 HTTP/1.1
Host: bank.example.com
Same as in 1)
proxy to server:
GET /?oauth_token=FOO-2 HTTP/1.1
Host: bank.example.com
Sane as in 2)
(server verifies the token "FOO-2" is valid for client 1 through the
proxy)
bank server to proxy:
HTTP/1.1 200 OK
other-stuff
proxy to client 1:
HTTP/1.1 200 OK
other-stuff
Attacker processes some URL records they somehow swiped from the
client transactions...
3) How can attacker swipe it, if the token was passed *as part of an
encrypted payload?*
attacker to proxy:
GET /?oauth_token=FOO HTTP/1.1
Host: bank.example.com
proxy to attacker:
HTTP/1.1 200 OK
stuff
... Oops.
attacker to proxy:
GET /?oauth_token=FOO-2 HTTP/1.1
Host: bank.example.com
proxy to attacker:
HTTP/1.1 200 OK
other-stuff
... Oops.
I assume for clarity that the server and client 1 have both correctly
implemented Bearer and are performing proper validation and expiry on
the query-string tokens.
The mitigation is for the server which implements Bearer to be sending
Cache-Control with one of the values: no-store, private,
proxy-revalidate and/or must-revalidate.
AYJ
Then it is the bank's problem, not OAuth's as far as I am concerned...
Igor
On 1/2/2012 7:36 PM, Amos Jeffries wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
