On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon julian@yon.org.uk wrote:
On 04/11/11 21:37, Watson Ladd wrote:
On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom rransom.8774@gmail.com 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