On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon <[email protected]> wrote: > On 04/11/11 21:37, Watson Ladd wrote: >> On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom <[email protected]> wrote: >>> | Should the client send a string of the form "GET >>> | /?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE >>> | cell, where "correct+horse+battery+staple" is a semi-plausible search >>> | phrase derived from the HMAC in some way? >> >> Seems to me at that point we are hosed anyway. If you see >> correct+horse+battery+staple >> and the response is garbled data, not an HTTP response, its probably >> something unusual. >> Bridge descriptors should include enough information for Tor to ensure >> that the TLS connection is safe. > > 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. > > (NB. I'm not a cryptographer; feel free to tell me where the flaw in my > logic lies)
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. Sincerely, Watson Ladd _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
