skip to content

What does extended master secret change about how a TLS 1.2 master secret is derived, and why?

level: seniorimportance: nice to knowfreq 26%

answer

  1. What the derivation actually hashes
  2. Two randoms are not a transcript
  3. session_hash through the ClientKeyExchange
  4. One master secret, one handshake
  5. TLS 1.3 mixes the transcript throughout

basics

~20 s

It derives the TLS 1.2 master secret from a hash of the handshake messages instead of the two hello random values, so a master secret can belong to only the one handshake that produced it.

solid answer

~50 s

Plain TLS 1.2 computes the master secret as a pseudorandom function over the premaster secret, the label `"master secret"`, and the ClientHello and ServerHello random values — and nothing else about the handshake. Two different connections can therefore be steered into deriving the **same** master secret by an intermediary that terminates both and arranges for the same premaster and the same randoms, after which material bound to one connection can be spliced onto the other. The extended master secret repair (RFC 7627) swaps those inputs: the label becomes `"extended master secret"` and the value hashed is `session_hash`, a digest of every handshake message through the ClientKeyExchange — including the certificates and the key exchange, which differ between the two connections. TLS 1.3 needs no such extension, because every secret it derives already runs over the running transcript.

code

pseudocode · 11 lines
pseudocode
TLS 1.2, without the extension:
  master_secret = PRF(pre_master_secret,
                      "master secret",
                      ClientHello.random + ServerHello.random)

TLS 1.2, with extended master secret:
  session_hash  = Hash(all handshake messages
                       from ClientHello through ClientKeyExchange)
  master_secret = PRF(pre_master_secret,
                      "extended master secret",
                      session_hash)

go deeper

for a junior

Recall the one-line change: the master secret is computed over a hash of the handshake messages rather than over the two hello random values.

for a middle

Explain which inputs the original derivation had and what session_hash adds — the certificate and the key exchange — and that the premaster secret is still the secret input.

for a senior

Describe the failure it closes in mechanism terms: two connections forced to the same master secret, so material from one can be presented on the other, and be clear about what it does not fix.

for a principal

Treat it as the template for retrofitting a binding into a deployed protocol: negotiated, optional by construction, and leaving the estate a policy decision about peers that will not offer it.

This is a small change to one line of a derivation, and it is worth knowing because it is the clearest example in TLS of a secret that was strong but **unbound** — correct as a value, and attached to nothing in particular. ## What the original derivation hashed In TLS 1.2 the master secret is produced by the pseudorandom function from three inputs: the `pre_master_secret`, the fixed label `"master secret"`, and the concatenation of `ClientHello.random` and `ServerHello.random`. That is the whole input set. Notice what is **absent**: - the server's certificate; - the named group and the key-exchange values; - the offered cipher suites and extensions; - the server name the client asked for. None of them reaches the derivation. Two handshakes that differ in every one of those fields still produce the same master secret if the premaster secret and the two randoms happen to match. ## Why that mattered The randoms are not secret — they travel in the clear — and in some exchange shapes the premaster secret is chosen or known by a party in the middle. An intermediary that terminates one connection from a client and opens a second to a server can arrange for both to carry the same randoms and the same premaster secret, giving **two distinct connections one identical master secret**. Everything keyed off that secret then stops distinguishing them, and material established on one connection can be presented on the other as though it belonged there. The defect is not that the secret was guessable; it is that it did not identify which handshake it came from. ## What the extension changes With extended master secret negotiated, the derivation becomes: 1. compute `session_hash` — a digest of all handshake messages sent so far, from the ClientHello through the ClientKeyExchange, in order; 2. compute the master secret from the premaster secret, the label `"extended master secret"`, and `session_hash`. The premaster secret is still the secret input; only the contextual input changes. But `session_hash` covers the certificate the server sent, the key-exchange messages, the negotiated suite and the extensions — so two connections that differ anywhere in that span cannot arrive at the same master secret, whatever an intermediary does with the randoms. | | Plain TLS 1.2 | With extended master secret | |---|---|---| | Label | `"master secret"` | `"extended master secret"` | | Contextual input | two hello random values | `session_hash` over the handshake so far | | Covers the certificate | no | yes | | Covers the key exchange | no | yes | | Same secret possible on two handshakes | yes, if inputs are forced to match | no | ## Both sides must want it It is a negotiated extension: the client offers it, the server echoes it, and only then does the derivation change. That is the usual shape of a retrofit to a deployed protocol — a peer that does not understand the extension must still be able to complete a handshake, so the repair cannot simply be switched on unilaterally. A deployment that requires the binding therefore has to decide what to do about peers that do not offer it, which is a policy question rather than a protocol one. ## Why TLS 1.3 has no equivalent TLS 1.3 does not define this extension because it does not need it. Its key schedule derives every secret through `Derive-Secret`, which takes the running transcript hash as an input at each step, so the binding that the extension retrofits onto TLS 1.2 is structural in 1.3. There is nothing to negotiate and nothing that can be omitted. ## What it does not do This is the part most often overstated, so state the limit: - It does **not** make the master secret longer or harder to guess. The size is unchanged. - It does **not** help a recording made under key transport. If the premaster secret was mailed under a long-lived key, that key still recovers it; binding the derivation to a transcript does not change what a stored capture yields. - It does **not** change which named group or cipher was negotiated. It only records, inside the derived secret, what those choices were. It buys exactly one property: a master secret that belongs to one handshake and cannot be made to belong to a second.

  • Which handshake messages does session_hash cover, and which does it not?
    Every handshake message in order from the ClientHello through the ClientKeyExchange — the hellos, the server's certificate, the key-exchange messages. It stops there, so the `Finished` messages are outside it: they are computed after the master secret exists and cannot be one of its inputs.
  • Why is this a negotiated extension rather than simply a corrected derivation?
    Because it was retrofitted onto a deployed protocol. Both peers must understand it for the derivation to change, and a peer that does not offer it still has to be able to complete a handshake. Whether to refuse such peers is a deployment policy decision, not something the protocol settles.
  • Why does TLS 1.3 define no equivalent extension?
    Because its key schedule already takes the running transcript hash as an input at each derivation step via `Derive-Secret`. The binding the extension adds to TLS 1.2 is structural in TLS 1.3, so there is nothing to negotiate and no way to leave it out.

A receipt showing only the date can be attached to a different purchase; itemising the whole transaction on it cannot.

saying these in an interview costs you the question

  • Thinks it lengthens or otherwise strengthens the master secret itself.
  • Says it is a TLS 1.3 feature rather than a TLS 1.2 repair.
  • Believes the hello randoms already bind a secret to one handshake.
  • Claims it replaces the premaster secret as the derivation's secret input.
  • Thinks it protects a recorded session from a later key compromise.
  • Assumes it applies whenever one side supports it.