In practice
Hybrid encryption
TLS uses both public-key cryptography and symmetric encryption. This combination is no mere whim: each approach compensates for the other’s shortcomings.
The speed issue
Public-key cryptography is slow. Operations involve numbers running to hundreds of digits. Encrypting an entire video using RSA would take an absurdly long time.
Symmetric encryption, on the other hand, is very fast — modern processors execute AES using dedicated instructions and process gigabytes per second. But it requires a key to be shared in advance, which brings us back to the original problem.
The hybrid solution
(1) DH -----------------> K (a one-off, expensive)
(2) P --[ AES-GCM, K ]--> C (all traffic, fast)
The asymmetric part, which is computationally expensive, is used only once to establish a short session key. All subsequent traffic is then encrypted using symmetric encryption.
You get the flexibility of public-key cryptography — no pre-shared secret — and the speed of symmetric encryption.
Persistent confidentiality
Modern versions go a step further. The session key is generated using an ephemeral Diffie-Hellman: the exponents are randomly generated for each connection and then discarded.
A remarkable consequence of this is that if the server’s private key is stolen next year, conversations recorded today remain unreadable. The thief may be able to impersonate the server in the future, but cannot go back in time.
This is forward secrecy, which is mandatory in TLS 1.3.
What this changes
This property addresses a very real threat: recording encrypted traffic today whilst relying on a key to be obtained at a later date. Without forward secrecy, a single stolen key unlocks years of archives. With it, each connection would have to be compromised separately.

