extended_master_secret
extended_master_secret ties TLS 1.2 session keys to the full handshake, blocking the triple handshake attack.
What it is
extended_master_secret (extension 23) is defined in RFC 7627. In TLS 1.2 the master secret used to be computed only from the premaster secret and the two random values, which allowed the triple handshake attack: an attacker could make two different connections end up with the same master secret.
With this extension, both sides derive the master secret from a hash of the handshake messages up to the ClientKeyExchange instead, so each connection gets a unique secret tied to everything that was negotiated.
TLS 1.3 always derives its keys from the transcript, so the extension matters only for TLS 1.2. Modern clients send it to protect any TLS 1.2 connection they may end up with.
The extension is empty in the ClientHello: its presence alone is the request. The server confirms it by echoing the extension, and from then on both sides use the transcript-based master secret.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 11 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
Every measured client except macOS curl sends it. Positions vary a lot: 1st for curl-impersonate chrome116, 2nd for the ff117 profile, 4th for Go net/http, 6th for Debian curl, 7th for Python requests and Guzzle, 8th for httpx and Node.js fetch, 11th for curl_cffi.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for extended_master_secret in the TLS details.
Run the TLS fingerprint test