On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis desnacked@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,