Some initial analysis on the new "Triple Handshake Attack" and Tor
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.)
On Mon, Mar 3, 2014 at 6:45 PM, Nick Mathewson <nickm@torproject.org> 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 tor-dev@lists.torproject.org 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
On Mon, Mar 3, 2014 at 10:37 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
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.
To make sure I understand, it's the ECDHE that's the defense here: unlike DHE, ECDHE implementations don't let the attacker pick an arbitrary set of parameters which might not define a real group, and so if ECDHE is used, the attacker can't force two connections to share the same keys. I guess this is another "defense in depth" item: as of Tor 0.2.4.x*, the preferred ciphersuites are all ECDHE ones. But that isn't quite good enough, since non-ECDHE ciphersuites are still supported, so an attacker can simply pretend not to support them when talking to the client and the server. It would be helpful to know what fraction of 0.2.4.x servers support ECDHE ciphersuites today. That would let us figure out what obstacles there might be to dropping non-ECDHE ciphersuites in the future. * Assuming you're built with a good enough version of OpenSSL that doesn't have ECC turned off. best wishes, -- Nick
On Tue, Mar 4, 2014 at 7:05 AM, Nick Mathewson <nickm@alum.mit.edu> wrote:
On Mon, Mar 3, 2014 at 10:37 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
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.
To make sure I understand, it's the ECDHE that's the defense here: unlike DHE, ECDHE implementations don't let the attacker pick an arbitrary set of parameters which might not define a real group, and so if ECDHE is used, the attacker can't force two connections to share the same keys.
That's exactly correct.
I guess this is another "defense in depth" item: as of Tor 0.2.4.x*, the preferred ciphersuites are all ECDHE ones. But that isn't quite good enough, since non-ECDHE ciphersuites are still supported, so an attacker can simply pretend not to support them when talking to the client and the server.
It would be helpful to know what fraction of 0.2.4.x servers support ECDHE ciphersuites today. That would let us figure out what obstacles there might be to dropping non-ECDHE ciphersuites in the future.
* Assuming you're built with a good enough version of OpenSSL that doesn't have ECC turned off.
best wishes, -- Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org 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
04.03.2014 03:45, Nick Mathewson:
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.)
Hello Nick, thank you for the education. :) Since this is somewhat "important" for the list it is sent to it. You say both presented a "certificate chain". For me this is what SSL/TLS provides with CA certificate -> Sub CA certificate -> website certificate. Did Tor had a similar implementation where there was an actual chain of certificates? I am (and was) aware of not enabling some ciphers/cipher-suits in the server-hello to look not too different, as well as disabling some in the client-hello to look like Firefox connecting to Apache. Best Regards, Sebastian G. (bastik)
On Wed, Mar 5, 2014 at 1:36 PM, Sebastian G. <bastik.tor> <bastik.tor@googlemail.com> wrote:
04.03.2014 03:45, Nick Mathewson:
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.)
Hello Nick,
thank you for the education. :)
Since this is somewhat "important" for the list it is sent to it.
You say both presented a "certificate chain". For me this is what SSL/TLS provides with
CA certificate -> Sub CA certificate -> website certificate.
Did Tor had a similar implementation where there was an actual chain of certificates?>
Yes; have a look at the "v1 link handshake" as described in tor-spec.txt. The certificate chain doesn't involve a CA, but rather it was: Identity certificate -> Short-term link certificate The advantage to having multiple layers of keys is: * It provides another layer of forward secrecy by periodic discarding of private keys used for actual communication. * It makes it easier to keep identity keys offline to mitigate the effects of key compromise. (That's not fully possible in current Tor designs, because a Tor node needs its identity key to sign descriptors periodically. But see proposal 220 for a way to get into a position where we can support this.) yrs, -- Nick
participants (4)
-
Nick Mathewson -
Nick Mathewson -
Sebastian G. <bastik.tor> -
Watson Ladd