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

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2012-01-17, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
> On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked@xxxxxxxxx>
> 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.

Proposal 190 is only meant to resist identification of a bridge as a
bridge by an attacker actively probing it.  A MITM attacker is far
more likely to be trying to identify the client as a Tor client, so
clients which need to resist MITM attacks must detect them before
reaching the point in the protocol where it would send the AUTHORIZE
cell (thereby identifying it as a Tor client).


> 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.

With that hack on top of the v3 protocol, any client able to detect
that a bridge is not being MITMed can impersonate the bridge through
the TLS handshake, until after the (honest, victim) client speaks the
Tor protocol at the fake bridge.


The solution is:

* Add a v4 link protocol in which the bridge/relay publishes a list of
fingerprints and cert-chain positions of link certificates in its
descriptor, and the client verifies that the TLS server it's
connecting to presents a cert chain such that one certificate's
fingerprint and position in the cert chain matches one of the
fingerprint/position pairs in the server descriptor.

* Add a v4link=(FINGERPRINT,POSITION,IS-POSITION-RELATIVE-TO-ROOT-OR-LEAF),...
item to the Bridge line parser.

* ...

* Now TLS takes care of MITM detection for us, because we're using it
correctly for the first time since the v1 handshake.  Profit.

* Add EXTEND2 cells so relay-to-relay connections can use v4 links.


Robert Ransom
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev