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

[George Kadianakis]

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

> On 05/11/11 03:21, George Kadianakis wrote:
>> 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.
>
> A valid concern. Also applies to the ETag proposal.
>
>> 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
>
> My thought was that it's not too hard to proxy to a real webserver for
> content and inject/modify headers as required.
>
>> 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. 
>
> We're really talking about steganography here rather than a true covert
> channel. I believe the purpose is to avoid bridge enumeration due to the
> initial connection having a fingerprint? So you need an invisible method
> of authentication. It may be that distributing more information to
> bridge users out-of-band is actually the best approach. But to me the
> advantage of a technical solution is increased resistance to social
> engineering.
>
>> 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.
>
> That's certainly subtle. You're left with the problem of what the client
> should do if it can't authenticate the bridge. It still needs to send
> something down the pipe that it opened, and the server still needs to
> respond to that, otherwise the unused connection will look suspicious.
>
>
> J

Thanks for the ideas and the interest guys! 

I think it's time to reroute this thread towards comments on proposal
189 and scanning resistance; that is resistance against adversaries
who scan hosts to find bridges.

We will surely need a different thread and a different proposal for
resistance against censors using MITM attacks to detect bridges.