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

[Nick Mathewson]

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.

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,
-- 
Nick