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

Tue Mar 4 03:37:36 UTC 2014

On Mon, Mar 3, 2014 at 6:45 PM, Nick Mathewson <nickm at 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 at 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