On 4/01/2012 3:58 p.m., Igor Faynberg wrote:
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..
The client does too, surely.
Fidelity, well;
* it is going to cache the reply for re-use, <=== this is what I worry
about.
* it is going to log the URL+token for a longish term,
* it may pass the URL+token in unencrypted packets (via ICP, HTCP,
UDP syslog) to any peers it may have,
Given these risks are all internal to the security domain and so very
slight, they are still weak points in the transactions long-term integrity.
Adding the cache-controls erases the risks related to caching. With
correct CC headers URL replay would fail even if TLS were not present.
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?*
In the last year or so it has become safe to assume SSL/TLS is
compromised by MITM. Or alternatively some secondary infection at one of
the end points. Paranoia dictates that someone will figure it out
somehow if the stakes are high enough. When they do, its a good idea to
have the rest of the system firmly sealed.
The given sequence was for the reverse-proxy. The alternative scenario
is an identical sequence with a SSL interception proxy. For example an
installation of: http://wiki.squid-cache.org/Features/SslBump. In that
alternative the proxy is outside the servers security domain and inside
some third-party ISP domain at the user end.
AYJ
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
