In a static RSA TLS 1.2 handshake, which message carried the premaster secret, and what does TLS 1.3 send instead?

Consider a vote-tally transmitter uploading precinct results, and an adversary who simply records the upload and keeps it. What that recording is worth later depends entirely on **how the two ends reached their shared secret** — and TLS 1.2 offered two mechanically different answers to that, of which TLS 1.3 kept only one. ## Key transport: the secret was mailed In a static RSA handshake, the server's certificate was not only an identity claim; its public key was an encryption key. The client generated a 48-byte `pre_master_secret` (two version bytes and 46 random bytes), encrypted it under that RSA public key, and put the resulting `EncryptedPreMasterSecret` in `client_key_exchange(16)`. The server decrypted it with the matching private key, and both sides ran that secret through the TLS 1.2 pseudorandom function to produce the master secret and from there every record key. Two details matter: - There was **no** `ServerKeyExchange (12)` message in this shape. The server contributed no key-exchange value of its own; the client chose the secret unilaterally. - The one long-lived private key behind the certificate was therefore a **decryption** key, used on every connection for years. ## Key agreement: nothing secret was sent The ephemeral shape of TLS 1.2 looked different on the wire. The server sent `ServerKeyExchange (12)` carrying the named group it had selected and a freshly generated public value, plus a signature over those parameters made with the private key its certificate binds. `client_key_exchange(16)` then carried the client's own ephemeral public value. Each side combined its private value with the peer's public one; the premaster secret was computed, never transmitted. Here the long-lived key **signs** — it proves who chose the server's ephemeral value — and decrypts nothing. ## What TLS 1.3 kept TLS 1.3 removed key transport. There is no `client_key_exchange(16)` and no `ServerKeyExchange (12)`; both ephemeral public values travel in `key_share(51)` in the first two flights, and the certificate's private key is used for exactly one thing in the handshake — signing, in `CertificateVerify`. | | TLS 1.2 static RSA | TLS 1.2 ephemeral | TLS 1.3 | |---|---|---|---| | Secret reaches the server by | encryption under the certificate key | agreement from two public values | agreement from two public values | | Server key-exchange message | none | `ServerKeyExchange (12)` | none — `key_share(51)` | | Client key-exchange message | `client_key_exchange(16)` | `client_key_exchange(16)` | none — `key_share(51)` | | Certificate's private key | decrypts | signs | signs | ## What the stored recording is worth This is where the mechanism shows up operationally. With key transport, the entire premaster secret is present in the recording — as ciphertext under a key that outlives the connection by years. Anyone who later obtains that private key, by any route, decrypts the `EncryptedPreMasterSecret`, reruns the same derivation over the hello randoms (which were sent in the clear and are in the recording too), and reads every record in that session. Rotating the certificate afterwards does not help the sessions already captured: the key that opens them has already been copied. With an agreement exchange, the recording holds both **public** values and neither private one. The certificate key cannot decrypt anything in it, because nothing in it was ever encrypted to that key. The ephemeral private values existed only in the two hosts' memory for the life of the handshake. ## Reading this on a real connection The practical form of the question is usually diagnostic rather than theoretical: 1. Which TLS version did the connection actually negotiate? A 1.3 connection cannot have used key transport, because the mechanism is gone. 2. If 1.2, did it negotiate an ephemeral exchange or a static RSA one? That, not the version number, decides what a capture is worth. 3. What is the certificate's private key still able to do? In either 1.2 shape it can impersonate the server on new connections; only in the transport shape does it also open recorded ones. Keeping those three apart is what separates an answer about mechanism from an answer about vocabulary.