[tor-dev] Proposal 190: Password-based Bridge Client Authorization

[George Kadianakis]

Nick Mathewson <nickm at alum.mit.edu> writes:

> On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked at gmail.com> wrote:
>
>> 3.2. AUTHORIZE cell format
>>
>>   In shared-secret-based authorization, the MethodFields field of the
>>   AUTHORIZE cell becomes:
>>
>>       'shared_secret'               [10 octets]
>>
>>   where:
>>
>>   'shared_secret', is the shared secret between the bridge operator
>>                    and the bridge client.
>
> No, dumping the HMAC seems like a step backwards.  In practice,
> bridges are needed exactly in those cases where we're worried about
> active attacks between clients and the Tor network.  There's no point
> in revising a protocol proposal to be MORE vulnerable to MITM;
> instead, we need one that is less vulnerable.
>
> Marking this proposal needs-revision.  Not sure what the actual
> solution is though. One option might be to look for a way to signal
> (undetectably) to the client that the server knows what it's doing as
> part of the TLS handshake. For example, by building the
> ServerHello.random structure such that instead of having 28 random
> bytes and 4 bytes of time, it has 16 random bytes, 4 bytes of time,
> and 12 bytes based on a HMAC of (the 16 random bytes, the 4 time
> bytes, the ClientHello.Random, and the certificate that it will send).
>  Yuck!  But it might work.  It would need analysis, I guess.
>

Hm, which problem is this idea a solution to?

I seem to recall that the biggest issue with 190 trying to protect
against MITM attacks, was the fact that even though the MITM won't be
able to capture the bridge's password, the Client will still happily
send an AUTHORIZE cell to the MITM, revealing the fact that it's a
connection to a Tor bridge.

I'm not sure if your idea tries to solve the above problem, but an
HMAC of (the 16 random bytes, the 4 time bytes, the
ClientHello.Random, and the certificate that it will send) looks
forgeable by an adversary, leaving the Client to believe that he is
speaking with the correct Tor bridge.

By the way, section 5.1 of proposal 191 tries to solve the above
problem by tagging the SSL handshake with the shared-secret of
proposal 190.

Also, I doubt that vanilla OpenSSL will let us toy with
{Server,Client}Hello.Random. I think that's one of the reasons that
Telex ended up with an OpenSSL patch [0].

> I'm probably being too telegraphic here; I should try to expand this
> into a real idea if people don't think it's a total nonstarter for
> some reason.
>
> yrs,

So, after considering the above problems, we decided to split the
bridge-password problem into two parts, proposal 190 which
authenticates the Client to the Bridge, and proposal 191 which
authenticates the Bridge to the Client.

Building on the above thought, if proposals 190 and 191 authenticate
the two parties based on trusted credentials shared off-band, the v3
link protocol becomes somewhat obsolete, and we are talking about a
new link protocol which two-way authenticates the bridge and the
bridge client based on shared-secrets.

[0]: Did the Telex people clean up the patch, generalize it, and post
it in openssl-dev? Having configurable {Server,Client}Hello.Random in
a future version of OpenSSL would be neat.