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

[George Kadianakis]

Julian Yon <julian at yon.org.uk> writes:

> 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)
>
> Julian

There are some things in these HTTP solutions that make me nervous.

In the "GET /?q=correct+horse+battery+staple\r\n\r\n" client-side case
we will have to build HTTP header spoofing into the tor client, which
is not fun since modern browsers send loads of HTTP headers in their
first GET.

In the Etags/Cookies/whatever server-side case we will probably have
to build some sort of 'valid document'/'innocuous webpage' generator
into the Tor bridge, which is also not fun. Fortunately, we might be
able to reuse such a construction when Bridge Passwords fail:
https://lists.torproject.org/pipermail/tor-dev/2011-October/002996.html

Still, I would very much enjoy if we could find a way to authenticate
the bridge using the shared secret without relying on HTTP covert
channel wizardry. 

I've been thinking of having bridges that use Bridge Passwords, "tag"
their SSL certificate, say the Serial Number, with their password, and
have clients validate them before proceeding with AUTHORIZE cells.