Julian Yon <[email protected]> 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. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
