The key exchange component of a cipher suite determines how the client and server agree on the shared secret that becomes the AES session key. This choice has massive security implications, particularly around forward secrecy.
In RSA key exchange, the client generates a random āpre-master secret,ā encrypts it with the serverās RSA public key (from the certificate), and sends it to the server. The server decrypts it with its private key. Both sides derive the session keys from this pre-master secret.
Simple and straightforward. But it has a fatal flaw.
Think of it like a building where every apartment uses the same master key. Convenient for the landlord. But if that master key is ever copied, every apartment in the building is compromised, including apartments where tenants moved out years ago.
The serverās RSA private key is that master key. Itās long-lived. It sits on the server for months or years. If that key is ever compromised, through a server breach, a legal subpoena, a disgruntled employee, or a future cryptographic breakthrough, an attacker who recorded past traffic can decrypt all of it.
Every session used the same server private key to decrypt the pre-master secret. One key compromise exposes years of data.
graph TD
A[Attacker records encrypted traffic for years] --> B[Server private key is compromised]
B --> C[Attacker decrypts every recorded session]
C --> D[Years of data exposed]
With ephemeral key exchange, both sides generate fresh, temporary key pairs for every session. The shared secret is derived through Diffie-Hellman. After the session ends, the ephemeral keys are discarded.
Now imagine each apartment gets its own unique lock, and the key is melted down after the tenant leaves. Even if someone breaks into the landlordās office, they canāt open apartments that have already been vacated. The keys donāt exist anymore.
If the serverās long-term private key is compromised, the attacker can impersonate the server going forward, but they cannot decrypt past sessions. The ephemeral keys are gone. Thereās nothing to recover.
This property is called forward secrecy. Each sessionās secret is independent. Compromising one doesnāt compromise any other.
graph TD
A[Session 1: ephemeral keys generated and destroyed] --> B[Session 2: different ephemeral keys]
B --> C[Session 3: different ephemeral keys again]
D[Server private key compromised] --> E[Can impersonate server going forward]
D --> F[Cannot decrypt sessions 1, 2, or 3]
DHE (Diffie-Hellman Ephemeral): Uses classic Diffie-Hellman with large prime numbers. Requires 2048+ bit parameters for adequate security. Slower than ECDHE.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): Uses elliptic curve math. A 256-bit curve provides equivalent security to 3072-bit DHE. Faster and less bandwidth.
ECDHE is the standard choice. DHE is acceptable but slower. Both provide forward secrecy.
TLS 1.3 removed RSA key exchange entirely. Every TLS 1.3 connection uses ephemeral key exchange (ECDHE or DHE). Forward secrecy is no longer optional.
This was one of the most important changes in TLS 1.3. In TLS 1.2, a misconfigured server could use RSA key exchange and have no forward secrecy. In TLS 1.3, thatās impossible.
Quantum computers can break Diffie-Hellman and RSA. But with forward secrecy, a quantum computer would need to break each session individually. Without forward secrecy (RSA key exchange), breaking one key decrypts everything.
This is why the āharvest now, decrypt laterā threat is so concerning for traffic that used RSA key exchange. Traffic that used ECDHE is safer, because even a quantum computer would need to attack each session separately.