[tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells
marsh at extendedsubset.com
Sat Nov 5 04:35:31 UTC 2011
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:
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
The message input to the HMAC should probably include the rest of the
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
I would like other people to double-check my reasoning on this obviously.
More information about the tor-dev