Hi, all.
It looks like there was a new attack on the TLS protocol this morning. I think it doesn't affect Tor. But I should walk you through my reasoning to see if you agree.
I. The Triple Handshake attack.
Go read https://www.imperialviolet.org/2014/03/03/triplehandshake.html and then read https://secure-resumption.com/ . They explain the attack more carefully than I can do here.
Do *not* believe the part that says "renegotiation plus client certs" == doom until you have read the next part of this message.
II. The results of Triple Handshake on the v2 link protocol
Up until Tor 0.2.3, the preferred way for two servers to initiate a connection with one another was the "v2 link protocol", which uses both client certificates and renegotiation.
Fortunately, we do not support session renegotiation in Tor. So I believe we're in the clear there.
III. Implications for the v3 link protocol
As part of the V3 link protocol, the client (C) may authenticate to a server (S) by sending a signed authentication statement saying, among other things,
"Here's your identity key $S, here's a hash of the link certificate you used, here's my identity key $C, here's a hash of everything we've said to each other, here's the challenge message you just gave me, and I'm binding this assertion to this TLS connection using the master secret $foo".
This all gets signed with the client's key $C.
(Note that the "client" in this case is another Tor server. Regular users don't authenticate at all.)
Now, when we made that protocol [see proposal 176], we assumed that master secrets were unique to a single TLS connection. That assumption isn't true: the enabling part of the "Triple Handshake" attack is that the attacker (A) can arrange it so that C is connected to A, A is connected to S, and the TLS connections between A and S will share the same master secret.
Fortunately, I don't think this assumption can't be used to attack the v3 link protocol, since before the client will sent any such signed authentication statement, it insists on getting authentication from the server, in the form of a certificate chain leading from the server's identity key $S to the the key used for the TLS connection. So the client won't send a message containing the identity key "$S" to A, since A can't do a TLS handshake that is signed with any key that is signed with "$"S.
Also, we built some redundancy into our design. From proposal 176:
Even if the protocol didn't contain the TLSSECRET component, the server could [trust] the client's authentication, but it's a little trickier. The server knows that it is not getting a replayed AUTHENTICATE cell, since the cell authenticates (among other stuff) the server's AUTH_CHALLENGE cell, which it has never used before. The server knows that it is not getting a MITM'd AUTHENTICATE cell, since the cell includes a hash of the server's link certificate, which nobody else should have been able to use in a successful TLS negotiation.
Because the link certificate hash is part of the signed message, the attacker A can't actually get the client to give it a message that the server S will accept, even if the client *did* send the message before checking the server's entire certificate chain.
IV. Conclusions
1. Looks like we dodged another protocol bullet here.
2a. We should alter tor-spec.txt to make it clear that disabling TLS session resumption is even more necessary for security than we had thought.
2b. We should make it clear in tor spec that the client MUST NOT send an AUTHENTICATE cell before checking the CERTS cell and authenticating the server.
3. We should be sure to retire the v2 handshake nice and fast once 0.2.2 is unsupported. Renegotiation is an ugly corner of TLS that we should count ourselves glad to stumble out of.
4. We should look for more things to shove into the AUTHENTICATE cells in future versions of our protocol. The server certificate hash is a good start, but perhaps we can find more things to add.
5. We should revisit proposals to have Tor server <-> server communication use the v1 link protocol again. (That's the one where both sides present a certificate chain in their TLS handshake. We moved away from it because of protocol fingerprinting issues, before we'd hit upon pluggable transports as a better means for protocol obfuscation.) Due to our messed-up use of ciphersuites for signalling, we will have some tricky times designing this compatibly with existing Tors. But it might be our best long-term option if we can make it work. (IIRC Robert Ransom was advocating this.)
V. Acknowledgements
Thanks to Adam Langley for explaining some of the issues in this attack to me. Thanks to Steven Murdoch, Nicholas Hopper, and Adam Langley for reviewing an earlier draft of this mail. (At least one of them only had time for a cursory look, so please don't blame them for any mistakes here.)