- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 04 Jan 2012 18:07:18 +1300
- To: igor.faynberg@alcatel-lucent.com
- CC: Torsten Lodderstedt <torsten@lodderstedt.net>, ietf-http-wg@w3.org, oauth@ietf.org
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
Received on Wednesday, 4 January 2012 05:11:04 UTC