[tor-dev] Some initial analysis on the new "Triple Handshake Attack" and Tor

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

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.)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev