On 05/11/11 04:35, Marsh Ray wrote: > I love this line of thinking. But what if the MitM calls your bluff and > returns his own cookie, ETag header and a 302 Redirect to the same page? > What would the client do then? If the client did observe the redirect as > a browser would, he may be unable to try again for some time. Otherwise, > it would tend to confirm the status of the server as a Tor node. The problem is more general. What should the client do under any circumstance when it's unable to authenticate the bridge? Assuming a degree of justified paranoia, you probably want to leave it as long as possible before retrying. You may not even want to risk connecting to a *different* bridge, as it could be your own connection being intercepted and then you're just giving your adversary more information. > Seems like what we want is like TLS channel bindings to detect the MitM. > This is standardized. http://tools.ietf.org/html/rfc5056 > Microsoft IE+IIS implemented it, it thwarts their MitM tool: >> http://blogs.msdn.com/b/fiddler/archive/2010/10/15/fiddler-https-decryption-and-channel-binding-token-authentication-problems.aspx I don't know enough about this. I'll have to read the documents before I can comment. 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