Julian Yon julian@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.