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

[Watson Ladd]

On Fri, Nov 4, 2011 at 11:35 PM, Marsh Ray <marsh at extendedsubset.com> wrote:
> 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.
I don't know enough aboutTLS to comment on this. But I do know Telex
used a covert channel in TLS to good effect. Maybe we can do some kind
of similar stunt.
>
> 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
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin