Nick Mathewson nickm@alum.mit.edu writes:
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.
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.