Skip to main content

1. Introduction

1. Introduction​

In TLS [RFC5246], every session has a master_secret computed as:

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random)
                    [0..47];

where the pre_master_secret is the result of some key exchange protocol. For example, when the handshake uses an RSA ciphersuite, this value is generated uniformly at random by the client, whereas for Ephemeral Diffie-Hellman (DHE) ciphersuites, it is the result of a Diffie-Hellman key agreement.

As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same master_secret. For an RSA key exchange where the client is unauthenticated, this is achieved as follows. Suppose a client C connects to a server A. C does not realize that A is malicious and that A connects in the background to an honest server S and completes both handshakes. For simplicity, assume that C and S only use RSA ciphersuites.

  1. C sends a ClientHello to A, and A forwards it to S.

  2. S sends a ServerHello to A, and A forwards it to C.

  3. S sends a Certificate, containing its certificate chain, to A. A replaces it with its own certificate chain and sends it to C.

  4. S sends a ServerHelloDone to A, and A forwards it to C.

  5. C sends a ClientKeyExchange to A, containing the pre_master_secret, encrypted with A's public key. A decrypts the pre_master_secret, re-encrypts it with S's public key, and sends it on to S.

  6. C sends a Finished to A. A computes a Finished for its connection with S and sends it to S.

  7. S sends a Finished to A. A computes a Finished for its connection with C and sends it to C.

At this point, both connections (between C and A, and between A and S) have new sessions that share the same pre_master_secret, ClientHello.random, ServerHello.random, as well as other session parameters, including the session identifier and, optionally, the session ticket. Hence, the master_secret value will be equal for the two sessions and will be associated both at C and S with the same session ID, even though the server identities on the two connections are different. Recall that C only sees A's certificate and is unaware of A's connection with S. Moreover, the record keys on the two connections will also be the same.

The scenario above shows that TLS does not guarantee that the master secrets and keys used on different connections will be different. Even if client authentication is used, the scenario still works, except that the two sessions now differ on both client and server identities.

A similar scenario can be achieved when the handshake uses a DHE ciphersuite. Note that even if the client or server does not prefer using RSA or DHE, the attacker can force them to use it by offering only RSA or DHE in its hello messages. Handshakes using Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. Against more powerful adversaries, other key exchanges, such as Secure Remote Password (SRP) and Pre-Shared Key (PSK), have also been shown to be vulnerable [VERIFIED-BINDINGS].

Once A has synchronized the two connections, since the keys are the same on the two sides, it can step away and transparently forward messages between C and S, reading and modifying when it desires. In the key exchange literature, such occurrences are called unknown key-share attacks, since C and S share a secret but they both think that their secret is shared only with A. In themselves, these attacks do not break integrity or confidentiality between honest parties, but they offer a useful starting point from which to mount impersonation attacks on C and S.

Suppose C tries to resume its session on a new connection with A. A can then resume its session with S on a new connection and forward the abbreviated handshake messages unchanged between C and S. Since the abbreviated handshake only relies on the master secret for authentication and does not mention client or server identities, both handshakes complete successfully, resulting in the same session keys and the same handshake log. A still knows the connection keys and can send messages to both C and S.

Critically, at the new connection, even the handshake log is the same on C and S, thus defeating any man-in-the-middle protection scheme that relies on the uniqueness of finished messages, such as the secure renegotiation indication extension [RFC5746] or TLS channel bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on such session synchronization attacks. In particular, it describes a man-in-the-middle attack, called the "triple handshake", that circumvents the protections of [RFC5746] to break client-authenticated TLS renegotiation after session resumption. Similar attacks apply to application-level authentication mechanisms that rely on channel bindings [RFC5929] or on key material exported from TLS [RFC5705].

The underlying protocol issue leading to these attacks is that the TLS master secret is not guaranteed to be unique across sessions, since it is not context-bound to the full handshake that generated it. If we fix this problem in the initial master secret computation, then all these attacks can be prevented. This specification introduces a TLS extension that changes the way the master_secret value is computed in a full handshake by including the log of the handshake messages, so that different sessions will, by construction, have different master secrets. This prevents the attacks described in [TRIPLE-HS] and documented in Section 2.11 of [RFC7457].

Last updated on