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

[Watson Ladd <watsonbladd@xxxxxxxxx>]

On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon <julian@xxxxxxxxxx> wrote:
> On 04/11/11 21:37, Watson Ladd wrote:
>> On Fri, Nov 4, 2011 at 4:10 PM, Robert Ransom <rransom.8774@xxxxxxxxx> 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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev