On Fri, Nov 4, 2011 at 11:35 PM, Marsh Ray <[email protected]> wrote: > On 11/04/2011 09:19 PM, Watson Ladd wrote: >> >> On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon<[email protected]> 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. I don't know enough aboutTLS to comment on this. But I do know Telex used a covert channel in TLS to good effect. Maybe we can do some kind of similar stunt. > > 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 >
-- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
