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

[Marsh Ray]

On 11/04/2011 09:19 PM, Watson Ladd wrote:
> On Fri, Nov 4, 2011 at 8:01 PM, Julian Yon<julian at yon.org.uk>  wrote:
>>
>> What if the GET request can be anything innocuous (e.g. robots.txt,
>> index.html) and a valid document is sent back. But the headers include
>> an ETag derived in some way from the document content (or just the URL),
>> the shared secret and the bridge's TLS cert. If there's a MITM then the
>> client will compute a different ETag (due to the wrong cert) and can
>> close the connection. Otherwise it can immediately initiate the full
>> authorisation sequence.
>
> ETag is a great idea. We can then have bridges run their own web
> content or specify a page to serve up (with suitably redirected links)
> or forwards real requests to an actual webserver. This
> way every bridge can hide differently: serving tor.eff.org everywhere
> would be a dead giveaway.

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.

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

Tossing out an idea here: maybe this would work better backwards.

What if the client were to choose any innocuous-looking URL to request 
before initiating the handshake? Then he could bury an HMAC for a 
message including that URL in the TLS client_hello.random. The HMAC key 
could derived from the AUTHORIZE secret.

The client_random is supposed to contain a (generous) 28 random bytes 
transmitted in the clear. AFAICT, it's mainly to prevent replay attacks 
and is most important in special cases like session resumption and certs 
with fixed DH parameters. The encrypted premaster secret adds 
significant client-supplied entropy to the handshake too. Replacing some 
of the true random bytes with an HMAC formed from a secret key should 
not reduce the entropy (as perceived by the active attacker) too much I 
think.

The message input to the HMAC should probably include the rest of the 
client_random.

The client could also include some unpredictable stuff in the request 
(e.g., some meaningless cookies). This could prevent any net 
unpredictability loss in the client_random, so even if an attacker knew 
the AUTHORIZE secret it would not enable any additional attacks on the 
TLS handshake.

I would like other people to double-check my reasoning on this obviously.

- Marsh