[tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells

Watson Ladd watsonbladd at gmail.com
Sat Nov 5 02:19:45 UTC 2011

On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon <julian at 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 at 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.

Watson Ladd

More information about the tor-dev mailing list