Key Exchange and TLS 1.3

Alice and Bob want to communicate confidentially over a channel that Eve can read. They have never met. How do they establish a shared secret key?

Before 1976 this seemed impossible — the key had to be transmitted somehow, and any transmission Eve could intercept. Whitfield Diffie and Martin Hellman's 1976 paper showed a way: two parties can compute the same secret from information that is entirely public, as long as inverting a certain one-way function is hard.

This is the Diffie-Hellman key exchange. It does not provide authentication (Eve can still impersonate either party) — authentication is layered on top via certificates and digital signatures. The combination of key exchange + authentication + symmetric encryption is exactly what TLS provides.

Choose a large prime $p$ and a generator $g$ (both public). Alice picks secret $a$, Bob picks secret $b$:

$A = g^a \bmod p \quad (\text{Alice sends } A) \qquad B = g^b \bmod p \quad (\text{Bob sends } B)$

Both compute the shared secret:

$S = B^a \bmod p = g^{ab} \bmod p = A^b \bmod p$

Eve sees $g, p, A, B$ but must solve $a = \log_g A \bmod p$ — the discrete logarithm problem — to derive $S$. No polynomial-time classical algorithm is known for appropriately chosen $p$.

Parameters must be chosen carefully: $p$ must be a safe prime ($p = 2q+1$ where $q$ is also prime); $g$ should generate the large-order subgroup; $p$ must be at least 2048 bits (3072 for 128-bit security). Pre-computed DH parameters in old software were the target of the Logjam attack (2015), which broke 768-bit DH for export ciphersuites.

Elliptic Curve Diffie-Hellman (ECDH) replaces modular exponentiation with elliptic curve scalar multiplication:

$A = aG \quad (\text{Alice sends } A) \qquad B = bG \quad (\text{Bob sends } B)$

Shared secret:

$S = aB = a(bG) = b(aG) = bA$

Eve must solve $a$ from $(G, aG)$ — the ECDLP. With Curve25519 (the standard for TLS 1.3 key exchange, also called X25519), 256-bit scalars give ~128-bit security with keys that fit in 32 bytes.

X25519 is the mandatory key exchange in TLS 1.3. DH-FFDHE groups are also supported but less common.

Forward secrecy (also called perfect forward secrecy, PFS) means: a compromise of the server's long-term private key does not compromise past session keys.

Old TLS 1.2 cipher suites without PFS used the server's RSA private key to directly encrypt (or sign) the session key. An attacker who recorded traffic and later obtained the private key could decrypt all stored sessions retroactively. NSA bulk collection programs were designed around exactly this threat model.

PFS is achieved by using ephemeral DH or ECDH: fresh (a, b) values are generated per session and discarded immediately after the handshake. The server's long-term key is only used for authentication (signing the DH parameters), not key derivation.

TLS 1.3 mandates forward secrecy — all key exchange uses ECDHE or DHE. TLS 1.2 cipher suites starting with ECDHE_ or DHE_ have PFS; suites starting with RSA_ do not. Check your server's cipher list: if TLS_RSA_* suites are enabled, you are vulnerable to retrospective decryption.

ECDH gives Alice and Bob a shared secret, but how does Alice know she is talking to Bob and not Eve? The answer is certificates.

A certificate binds a public key to an identity (e.g., example.com) with a digital signature from a trusted third party — a Certificate Authority (CA). Your browser ships with ~150 root CA certificates in its trust store; any site certificate signed (directly or through intermediates) by one of those roots is trusted.

Chain of trust structure:

• Root CA: self-signed; kept offline in an HSM.
• Intermediate CA: signed by root; used for day-to-day issuance; can be revoked if compromised.
• Leaf/End-entity certificate: signed by an intermediate; contains the server's public key and domain names (CN / SAN).

During TLS, the server presents the leaf + intermediates. The client verifies the chain up to a trusted root. If any signature is invalid, or the leaf's domain doesn't match, the handshake fails with a certificate error — not a transparent downgrade.

A TLS 1.3 full handshake completes in one round-trip (1-RTT) before application data flows:

TLS 1.3 replaced the ad-hoc PRF-based key derivation of TLS 1.2 with a clean HKDF-based schedule:

1. ECDHE shared secret → (EC)DHE input.
2. Early secret = HKDF-Extract(0, PSK) (PSK = 0 for full handshake).
3. Handshake secret = HKDF-Extract(derived_early, ECDHE).
4. From handshake secret: derive client_handshake_traffic_secret and server_handshake_traffic_secret — used to encrypt the rest of the handshake.
5. Master secret = HKDF-Extract(derived_handshake, 0).
6. From master secret: derive client_application_traffic_secret and server_application_traffic_secret — used to encrypt application data.

Each direction uses independent keys — client→server and server→client never share a key. Re-keying (KeyUpdate) can happen mid-connection. The server's CertificateVerify signature covers a transcript hash of the entire handshake so far, binding the certificate to the specific key exchange.

A man-in-the-middle (MITM) attacker who controls the network can intercept the ClientHello, present their own certificate, and relay traffic. TLS stops this because the attacker cannot forge a certificate signed by a trusted root (without compromising a CA or the client's trust store).

Real-world MITM scenarios:

• Rogue CA: Lenovo's Superfish (2015) installed a self-signed root CA on laptops with the same private key on every unit — leaked, and trivially exploited.
• CA compromise: DigiNotar (2011) was hacked; fraudulent *.google.com certificates were issued and used to intercept Iranian Gmail.
• Certificate pinning: apps that hardcode the expected certificate or public key hash bypass the CA system. Defeats all CA-based MITM, but makes rotation painful.
• HSTS: Strict-Transport-Security header tells browsers to reject any non-TLS connection to a domain for a set period — prevents SSL stripping (downgrade to HTTP before TLS starts).

TLS 1.3 (RFC 8446, 2018) is a breaking cleanup of 1.2:

The 0-RTT resumption feature (session tickets) allows a client to send data in the first flight — but this data has no forward secrecy and is replay-vulnerable. Only use 0-RTT for idempotent requests (GET, not POST with side effects).

Getting TLS right in practice requires more than enabling HTTPS:

1. TLS version: disable TLS 1.0 and 1.1 (POODLE, BEAST). Enforce TLS 1.2+ minimum; prefer TLS 1.3 only where possible.
2. Cipher suite order: put ECDHE+AESGCM suites first; disable RSA key exchange suites in TLS 1.2.
3. Certificate management: automate renewal (Let's Encrypt / ACME) — human processes miss expirations. Expired certs cause outages, not security incidents, but they erode trust.
4. HSTS preloading: submit your domain to hstspreload.org for inclusion in browser preload lists — eliminates first-visit SSL stripping.
5. OCSP stapling: include the CA's revocation response in the handshake so clients don't need to make a separate revocation check (privacy + performance).
6. Pinning vs CT: Certificate Transparency (CT) logs are a scalable alternative to pinning — misissuance is publicly detectable; clients can require SCTs.

Validate your config with testssl.sh or Qualys SSL Labs; a grade below A- signals exploitable misconfigurations.