6. Security Considerations

6.1. Triple Handshake Preconditions and Impact

One way to mount a triple handshake attack is described in Section 1, along with a mention of the security mechanisms that break due to the attack; more in-depth discussion and diagrams can be found in [TRIPLE-HS]. Here, some further discussion is presented about attack preconditions and impact.

To mount a triple handshake attack, it must be possible to force the same master secret on two different sessions. For this to happen, two preconditions must be met:

The client, C, must be willing to connect to a malicious server, A. In certain contexts, like the web, this can be easily achieved, since a browser can be instructed to load content from an untrusted origin.
The pre-master secret must be synchronized on the two sessions. This is particularly easy to achieve with the RSA and DHE key exchanges, but under some conditions, ECDHE, SRP, and PSK key exchanges can be exploited to this effect as well.

Once the master secret is synchronized on two sessions, any security property that relies on the uniqueness of the master secret is compromised. For example, a TLS exporter [RFC5705] no longer provides a unique key bound to the current session.

TLS session resumption also relies on the uniqueness of the master secret to authenticate the resuming peers. Hence, if a synchronized session is resumed, the peers cannot be sure about each other's identities, and the attacker knows the connection keys. Clearly, a precondition to this step of the attack is that both client and server support session resumption (either via session identifier or session tickets [RFC5077]).

Additionally, in a synchronized abbreviated handshake, the whole transcript (which includes the verify_data values) is synchronized. So, after an abbreviated handshake, channel bindings like "tls-unique" [RFC5929] will not uniquely identify the connection anymore.

Synchronization of the verify_data in abbreviated handshakes also undermines the security guarantees of the renegotiation indication extension [RFC5746], re-enabling a prefix-injection flaw similar to the renegotiation attack [Ray09]. However, in a triple handshake attack, the client sees the server certificate changing across different full handshakes. Hence, a precondition to mount this stage of the attack is that the client accepts different certificates at each handshake, even if their common names do not match. Before the triple handshake attack was discovered, this used to be widespread behavior, at least among some web browsers; such browsers were hence vulnerable to the attack.

The extended master secret extension thwarts triple handshake attacks at their first stage by ensuring that different sessions necessarily end up with different master secret values. Hence, all security properties relying on the uniqueness of the master secret are now expected to hold. In particular, if a TLS session is protected by the extended master secret extension, it is safe to resume it, to use its channel bindings, and to allow for certificate changes across renegotiation, meaning that all certificates are controlled by the same peer. A symbolic cryptographic protocol analysis justifying the extended master secret extension appears in [VERIFIED-BINDINGS].

6.2. Cryptographic Properties of the Hash Function

The session hashes of two different sessions need to be distinct; hence, the Hash function used to compute the session_hash needs to be collision resistant. As such, hash functions such as MD5 or SHA1 are NOT RECOMMENDED.

We observe that the Hash function used in the Finished message computation already needs to be collision resistant for the renegotiation indication extension [RFC5746] to work, because a meaningful collision on the handshake messages (and hence on the verify_data) may re-enable the renegotiation attack [Ray09].

The hash function used to compute the session hash depends on the TLS protocol version. All current ciphersuites defined for TLS 1.2 use SHA256 or better, and so does the session hash. For earlier versions of the protocol, only MD5 and SHA1 can be assumed to be supported, and this document does not require legacy implementations to add support for new hash functions. In these versions, the session hash uses the concatenation of MD5 and SHA1, as in the Finished message.

6.3. Handshake Messages Included in the Session Hash

The session_hash is intended to encompass all relevant session information, including ciphersuite negotiation, key exchange messages, and client and server identities. The hash is needed to compute the extended master secret and hence must be available before the Finished messages.

This document sets the session_hash to cover all handshake messages up to and including the ClientKeyExchange. For existing TLS ciphersuites, these messages include all the significant contents of the new session -- CertificateVerify does not change the session content. At the same time, this allows the extended master secret to be computed immediately after the pre-master secret, so that implementations can shred the temporary pre-master secret from memory as early as possible.

It is possible that new ciphersuites or TLS extensions may include additional messages between ClientKeyExchange and Finished that add important session context. In such cases, some of the security guarantees of this specification may no longer apply, and new man-in-the-middle attacks may be possible. For example, if the client and server support the session ticket extension [RFC5077], the session hash does not cover the new session ticket sent by the server. Hence, a man-in-the-middle may be able to cause a client to store a session ticket that was not meant for the current session. Attacks based on this vector are not yet known, but applications that store additional information in session tickets beyond those covered in the session hash require careful analysis.

6.4. No SSL 3.0 Support

The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is equally vulnerable to triple handshake attacks, alongside other vulnerabilities stemming from its use of obsolete cryptographic constructions that are now considered weak. SSL 3.0 has been deprecated [RFC7568].

The countermeasure described in this document relies on a TLS extension and hence cannot be used with SSL 3.0. Clients and servers implementing this document SHOULD refuse SSL 3.0 handshakes. If they choose to support SSL 3.0, the resulting sessions MUST use the legacy master secret computation, and the interoperability considerations of Section 5.4 apply.