Key Exchange and Cipher Suites

TLS does not use just one algorithm — it needs several working together: one to agree on a shared secret, one to prove the server's identity, one to encrypt the data, and one to check it wasn't tampered with. A cipher suite bundles a specific choice for each of these into one name.

Client's supported cipher suites:
  TLS_AES_128_GCM_SHA256
  TLS_AES_256_GCM_SHA384
  TLS_CHACHA20_POLY1305_SHA256
        |
        v
Server picks one it also supports:
  -> TLS_AES_128_GCM_SHA256
        |
        v
Both sides now know exactly which algorithms to use
for the rest of the connection

During the handshake, the client sends a list of cipher suites it supports, ordered by preference. The server picks one from that list, which it also supports. From that point on, both sides know exactly which encryption and integrity algorithm to use.

Why this matters:

• Picking a weak cipher suite undermines the whole connection, no matter how strong TLS itself is.
• Servers are usually configured to only offer modern, secure cipher suites, and reject old weak ones.

TLS 1.3 cipher suite:

TLS_AES_128_GCM_SHA256
 |    |    |    |
 |    |    |    +-- SHA256: hash function used for the handshake's
 |    |    |         integrity checks (the "Finished" messages, etc.)
 |    |    +-------- GCM: the mode AES runs in, which also gives
 |    |                an integrity check on the encrypted data
 |    +------------- AES_128: the symmetric encryption algorithm
 |                     and key size
 +------------------ "TLS" prefix, just labels this as a TLS cipher suite

TLS 1.3 dropped key exchange and signature algorithm from the name entirely, because it only supports (EC)DHE key exchange now — there's nothing left to choose between, so it isn't part of the name.

TLS 1.2 cipher suite (longer, because more is configurable):

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 |    |      |      |    |    |
 |    |      |      |    |    +-- SHA256: hash used in the handshake
 |    |      |      |    +------- GCM: encryption mode
 |    |      |      +------------ AES_128: symmetric cipher
 |    |      +------------------- RSA: authentication/signature algorithm
 |    +-------------------------- ECDHE: key exchange algorithm
 +------------------------------- "TLS" prefix

The general pattern for TLS 1.2 names is: TLS_[key exchange]_[authentication]_WITH_[cipher]_[hash]. Being able to read these is useful when debugging connection failures, or when auditing which cipher suites a server allows.

Both RSA and ECDHE let a client and server agree on a shared secret. They get there in very different ways.

RSA key exchange (old TLS 1.2 option, removed in TLS 1.3):

Client generates a random secret
Client encrypts it with the server's public key (from its certificate)
   ------------------------------------------------->
Server decrypts it with its private key
Both sides now share the same secret

The client picks the secret, encrypts it, and sends it over. Anyone with the server's private key can decrypt it — including the same private key used for every connection to that server.

ECDHE (used by TLS 1.2 optionally, required by TLS 1.3):

Client generates a temporary key pair       Server generates a temporary key pair
Client sends its temporary public key  -->
                                        <--  Server sends its temporary public key

Client combines: (its private key) + (server's public key) --> shared secret
Server combines: (its private key) + (client's public key) --> shared secret
(both arrive at the same value, without ever transmitting it directly)

Neither side ever sends the actual shared secret over the network — it's computed independently on each side, from a mix of public and private values.

Why this matters — forward secrecy:

• With RSA key exchange, the same server private key is reused for every connection. If that private key ever leaks, an attacker who recorded past encrypted traffic can decrypt all of it, retroactively.
• With ECDHE, a fresh, temporary ("ephemeral") key pair is generated for every single connection, then thrown away. Even if the server's long-term private key leaks later, past sessions stay safe, because they never depended on that key for the actual secret.

This forward-secrecy gap is exactly why TLS 1.3 removed RSA key exchange and requires ECDHE (or DHE) for every connection.

Imagine an attacker records all of a company's encrypted traffic for a year, without being able to read any of it. Then, a year later, the server's private key gets stolen or leaked.

Without forward secrecy (e.g. RSA key exchange):
   stolen private key + recorded traffic --> attacker can decrypt everything, retroactively

With forward secrecy (e.g. ECDHE):
   stolen private key + recorded traffic --> attacker still can't decrypt past sessions
   (each session used its own temporary, now-deleted key)

Without forward secrecy, that leaked key can decrypt every recorded session from the past, because they all depended on that one long-term key. This is sometimes called "harvest now, decrypt later" — an attacker collects encrypted traffic today, hoping to crack it open later.

With forward secrecy, each session's actual encryption key is derived from a temporary key pair, generated fresh and discarded right after that one session ends. The server's long-term private key is only used to sign the exchange, proving its identity — never to directly produce the session's secret. So even a stolen long-term key can't unlock old traffic, because the temporary keys that mattered are already gone.

This is why forward secrecy is considered essential for modern TLS, and exactly why TLS 1.3 no longer allows RSA key exchange, only (EC)DHE-based methods that provide it by default.

TLS 1.3 only allows (EC)DHE-family key exchange. RSA key exchange, which was still allowed as an option in TLS 1.2, was removed entirely. There were a few converging reasons:

• No forward secrecy — as covered in the previous question, RSA key exchange reuses the server's long-term private key to protect every session's secret. One leaked key compromises every past session ever recorded.
• History of real attacks — RSA key exchange has repeatedly been the target of practical attacks, such as ROBOT (Return Of Bleichenbacher's Oracle Threat), which exploited subtle timing and error-response differences during RSA decryption to gradually decrypt captured traffic.
• It's not actually faster — RSA key exchange was sometimes assumed to be cheaper than ECDHE, but modern ECDHE implementations are fast enough that this is no longer a meaningful trade-off.
• Fewer options means a smaller attack surface — TLS 1.2 let a server operator, sometimes accidentally, keep a weak configuration enabled. TLS 1.3 simplifies its options down to a small set that is secure by default, rather than secure only if configured carefully.

The result is a protocol where you cannot even configure the insecure option, because it no longer exists.