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 -- 3072D/D2DE707D Julian Yon (2011 General Use) <pgp.2011@xxxxxx>
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev