On Mon, Mar 3, 2014 at 6:45 PM, Nick Mathewson <[email protected]> wrote: > 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.)
How about 6: Tor server to server connections should use ECDHE+ChaCha20 or GCM_AES ciphersuites only? This closes the UKS hole that enabled this attack to happen, and probably is a good idea anyway. Sincerely, Watson Ladd > > 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.) > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
