On 2012-01-17, Nick Mathewson nickm@alum.mit.edu wrote:
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.
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