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-...
I don't know enough about this. I'll have to read the documents before I can comment.
J