[tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells

[Julian Yon]

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 at jry.me>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20111105/f7b2ed09/attachment.pgp>