One common description of the TLS handshake says "the client encrypts a premaster secret with the server's public key". Why is that not what happens in a connection using ECDHE-RSA-AES128-GCM-SHA256, and why does the difference matter?
That description is the old RSA key exchange. With ECDHE the premaster secret is never sent at all: both sides compute it from temporary Diffie-Hellman values, and the RSA key only signs. So a stolen server key cannot decrypt recorded sessions (forward secrecy), which it could with RSA key exchange.
* What an attacker needs to decrypt a recording: the server key (RSA) or the discarded ephemeral keys (ECDHE). *
| RSA key exchange | ECDHE key exchange | |
|---|---|---|
| Premaster secret | Chosen by the client, sent encrypted with the server's RSA public key | Computed by both sides from each other's ephemeral public values, never sent |
| Role of the certificate key | Decrypts the premaster | Signs the server's ephemeral value |
| ServerKeyExchange message | Absent | Present (the log shows Server key exchange (12)) |
| Recorded traffic + later stolen key | Decryptable: the key unlocks every premaster ever sent | Not decryptable: the ephemeral keys are gone |
| TLS 1.3 | Removed | The only option (DHE or ECDHE) |
The same fact shows up in Wireshark: it can decrypt a capture with the server's private key only for RSA key exchange. For ECDHE sessions it needs the per-session secrets logged by an endpoint (an SSLKEYLOGFILE).
For a fleet of devices this is not academic: a device or server key leaks one day, and an attacker who recorded the traffic for years should still learn nothing from it.
Go deeper:
Wikipedia — Forward secrecy — the property, and why TLS 1.3 made it mandatory.- Wireshark wiki — TLS — decrypting with an RSA key versus a key log file, and why (EC)DHE needs the latter.
- Wikipedia — Elliptic-curve Diffie-Hellman — how two parties compute a shared secret over an open channel.