Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
updates
- rfc-5246 — The Transport Layer Security (TLS) Protocol Version 1.2
Extracted elements (24)
Mixing a hash of the key-exchange messages into master key derivation follows the recommendation that keys should be bound to the security contexts that compute them (NIST SP800-108) and is already used in SSH (RFC 4251). The extended master secret extends this principle to TLS full handshakes.
The session hash is defined to include all handshake messages up to and including ClientKeyExchange—but not CertificateVerify—because these messages capture all significant new-session content, and stopping at ClientKeyExchange allows the extended master secret to be computed immediately after the pre-master secret, enabling implementations to shred the temporary pre-master secret from memory as early as possible.
The TLS master secret in RFC 5246 is not cryptographically bound to the server certificate or other session parameters, allowing an active attacker (the 'triple handshake' attack) to synchronize two TLS sessions so they share the same master_secret. Any mechanism relying on master secret uniqueness—including session resumption, channel bindings, and renegotiation—is then vulnerable to man-in-the-middle attacks.
To interoperate with legacy peers, a TLS endpoint may accept full handshakes using the legacy master secret computation, but it must differentiate such sessions from extended-master-secret sessions by adding a flag to session state. Sessions without the extension are vulnerable to key-synchronization attacks and must not be used for application-level authentication.
A client implementing this document MUST send the extended_master_secret extension in its ClientHello in all handshakes (both full and abbreviated).
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.
Clients and servers SHOULD NOT accept handshakes that do not use the extended master secret, especially if they rely on features like compound authentication that fall into the vulnerable cases described in Section 6.1.
If a client receives a ServerHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy servers. If both sides continue without the extension, they MUST use the standard master secret derivation.
If a full handshake proceeds without the extended master secret extension, the client or server MUST NOT export any key material based on the new master secret for any subsequent application-level authentication. In particular, it MUST disable RFC 5705 keying material export and any EAP relying on compound authentication.
If a server implementing this document receives the extended_master_secret extension, it MUST include the extension in its ServerHello message.
If an abbreviated handshake resumes a session that does not use extended_master_secret, the client or server MUST NOT use the current handshake's verify_data for application-level authentication. The client MUST disable renegotiation and any use of the tls-unique channel binding (RFC 5929) on the current connection.
If both ClientHello and ServerHello contain the extension and a full handshake takes place, both client and server MUST use the extended master secret derivation algorithm defined in Section 4; all other cryptographic computations remain unchanged.
If the original session did not use extended_master_secret but the new ServerHello contains the extension, or if the original session used the extension but the new ServerHello does not, the client MUST abort the abbreviated handshake.
If the server receives a ClientHello without the extension, it SHOULD abort the handshake if it does not wish to interoperate with legacy clients. If it continues the handshake, it MUST NOT include the extension in the ServerHello.
The client SHOULD NOT offer an abbreviated handshake to resume a session that does not use an extended master secret; instead it SHOULD offer a full handshake.
The extended master secret replaces the RFC 5246 computation with: master_secret = PRF(pre_master_secret, 'extended master secret', session_hash)[0..47]. This substitutes the 'extended master secret' label for 'master secret' and session_hash for the concatenation of ClientHello.random and ServerHello.random, binding the master secret to all significant session parameters.
The 'extended_master_secret' TLS extension has extension type 0x0017 (decimal 23). Its extension_data field is empty, so the full on-wire encoding is 00 17 00 00 (hexadecimal). The extension is applicable to both TLS and DTLS.
The TLS session hash is defined as session_hash = Hash(handshake_messages), where handshake_messages is the concatenation of all Handshake structures from ClientHello through ClientKeyExchange inclusive, including type and length fields. For TLS 1.2, Hash is the function used in Finished computation; for earlier versions, it is the concatenation of MD5 and SHA1.
IANA has assigned extension code point 23 (0x0017) to the 'extended_master_secret' extension in the TLS ExtensionType Values registry, as specified in RFC 5246. This code point was already in use by prototype implementations.
SSL 3.0 is equally vulnerable to triple handshake attacks and uses obsolete cryptographic constructions. Since the extended master secret countermeasure relies on a TLS extension, it cannot be used with SSL 3.0, which has been deprecated by RFC 7568.
The Hash function used to compute session_hash must be collision resistant because distinct sessions require distinct session hashes. MD5 and SHA1 are NOT RECOMMENDED. TLS 1.2 ciphersuites use SHA-256 or better; earlier versions use the MD5+SHA1 concatenation as in the Finished message computation.
The session hash covers handshake messages up to and including ClientKeyExchange. New ciphersuites or extensions that add significant session context between ClientKeyExchange and Finished (e.g., session tickets sent by the server) may not be covered, potentially re-opening man-in-the-middle vectors; such applications require careful analysis.
The triple handshake attack requires two preconditions: (1) the client connects to a malicious server (easily achieved in browser contexts), and (2) the pre-master secret is synchronized across two sessions (straightforward with RSA and DHE, also possible with ECDHE when arbitrary explicit curves or small subgroups are allowed, and with SRP/PSK under some conditions). Once master secrets are synchronized, session resumption, TLS exporters, channel bindings, and renegotiation all lose their security guarantees.
The extended_master_secret extension is encoded as four bytes: type 00 17, followed by length 00 00, with no extension_data payload. This is the complete wire representation of the extension in ClientHello and ServerHello.