On 11/04/2011 09:19 PM, Watson Ladd wrote:
On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon<julian@xxxxxxxxxx> wrote:What if the GET request can be anything innocuous (e.g. robots.txt, index.html) and a valid document is sent back. But the headers include an ETag derived in some way from the document content (or just the URL), the shared secret and the bridge's TLS cert. If there's a MITM then the client will compute a different ETag (due to the wrong cert) and can close the connection. Otherwise it can immediately initiate the full authorisation sequence.ETag is a great idea. We can then have bridges run their own web content or specify a page to serve up (with suitably redirected links) or forwards real requests to an actual webserver. This way every bridge can hide differently: serving tor.eff.org everywhere would be a dead giveaway.
I love this line of thinking. But what if the MitM calls your bluff and returns his own cookie, ETag header and a 302 Redirect to the same page? What would the client do then? If the client did observe the redirect as a browser would, he may be unable to try again for some time. Otherwise, it would tend to confirm the status of the server as a Tor node.
Seems like what we want is like TLS channel bindings to detect the MitM. This is standardized. http://tools.ietf.org/html/rfc5056
Microsoft IE+IIS implemented it, it thwarts their MitM tool:
http://blogs.msdn.com/b/fiddler/archive/2010/10/15/fiddler-https-decryption-and-channel-binding-token-authentication-problems.aspx
Tossing out an idea here: maybe this would work better backwards.What if the client were to choose any innocuous-looking URL to request before initiating the handshake? Then he could bury an HMAC for a message including that URL in the TLS client_hello.random. The HMAC key could derived from the AUTHORIZE secret.
The client_random is supposed to contain a (generous) 28 random bytes transmitted in the clear. AFAICT, it's mainly to prevent replay attacks and is most important in special cases like session resumption and certs with fixed DH parameters. The encrypted premaster secret adds significant client-supplied entropy to the handshake too. Replacing some of the true random bytes with an HMAC formed from a secret key should not reduce the entropy (as perceived by the active attacker) too much I think.
The message input to the HMAC should probably include the rest of the client_random.
The client could also include some unpredictable stuff in the request (e.g., some meaningless cookies). This could prevent any net unpredictability loss in the client_random, so even if an attacker knew the AUTHORIZE secret it would not enable any additional attacks on the TLS handshake.
I would like other people to double-check my reasoning on this obviously. - Marsh _______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev