[tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
julian at yon.org.uk
Sat Nov 5 14:31:09 UTC 2011
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:
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
> 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.
3072D/D2DE707D Julian Yon (2011 General Use) <pgp.2011 at jry.me>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 294 bytes
Desc: OpenPGP digital signature
More information about the tor-dev