up:: In the Protocols MOC

TLS

TLS (Transport Layer Security) is the protocol that secures almost all data in transit on the internet, the cryptography running underneath the HTTPS padlock. Every session it protects does three jobs at once: it authenticates the server you’re talking to, it agrees on fresh secret keys with that server, and it encrypts the traffic that flows afterward. The quantum problem with TLS isn’t that the protocol is broken. It’s that two of the public-key pieces inside the handshake, the key exchange and the certificate signatures, rest on math a large quantum computer can solve, so the fix is to swap those pieces for quantum-safe ones while keeping TLS itself.

The short version:

• TLS is a framework, not one algorithm. It bundles authentication, key exchange, key derivation, and symmetric encryption into one handshake, and each piece has a different quantum exposure.
• The key exchange (ECDHE, or older RSA key transport) is the urgent piece. It’s what a harvest-now-decrypt-later attacker targets, because traffic captured today can be decrypted once a quantum computer arrives.
• The certificate signatures (RSA or ECDSA) are the slower track. Forging them needs a quantum computer that exists at the moment of the handshake, so there’s nothing to harvest, which buys more migration time.
• The symmetric encryption of the actual data (AES-GCM) survives the transition. It needs a larger key and stays in place.
• The migration path is hybrid key exchange first (classical X25519 and ML-KEM run together, group name X25519MLKEM768), then post-quantum certificate signatures later once the ecosystem catches up.

Think of a TLS connection like sealing a diplomatic pouch before it leaves the embassy. First you check the courier’s credentials so you know he’s really from the ministry (authentication). Then you and the ministry agree on a one-time lock combination that only the two of you know (key exchange). Then everything inside the pouch travels under that lock (symmetric encryption). Quantum computing threatens the credential check and the combination-setting step. The lock on the pouch itself is fine. You don’t throw out the pouch system. You upgrade how the combination gets set and how the credentials get signed.

What is TLS?

TLS is a cryptographic protocol that lets two systems set up a secure conversation over an untrusted network. It sits above the transport layer, usually running over TCP, and it’s the foundation for HTTPS and for a huge amount of other traffic, customer APIs, internal service-to-service calls, admin consoles, mobile backends, machine-to-machine identity. When people say a connection is “encrypted in transit,” they almost always mean TLS is doing the work.

The important thing to hold onto is that TLS is a framework, not a single primitive. One TLS session coordinates several different cryptographic functions:

1. Endpoint authentication through certificates and digital signatures, so you know the server is who it claims to be.
2. Key establishment (key exchange), where the two sides derive a shared secret no eavesdropper can reconstruct.
3. Session key derivation, turning that shared secret into the actual traffic keys.
4. Symmetric encryption of the application data, using those traffic keys.
5. Integrity protection and transcript binding, so the messages can’t be tampered with or replayed.

Because these are separate functions using separate algorithms, “is TLS quantum-safe?” has no single answer. The right question is which mechanism is doing each job in a given deployment, because each one faces the quantum threat differently.

The two protocol versions that matter today are TLS 1.2 and TLS 1.3. Everything older, the SSL versions and early TLS, is deprecated and shouldn’t be treated as a secure baseline. RFC 8996 formally deprecated TLS 1.0 and TLS 1.1 in 2021.

Sources: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, datatracker.ietf.org.

Source: K. Moriarty, S. Farrell, “Deprecating TLS 1.0 and TLS 1.1,” RFC 8996, March 2021, datatracker.ietf.org.

Where does cryptography live in TLS?

Cryptography in TLS lives in two phases, and only one of them is where the quantum-vulnerable math sits. Understanding the split is the whole game.

The handshake phase is where the two sides negotiate parameters, prove identity, and establish shared secrets. This is where the public-key cryptography runs, and this is where the quantum exposure lives. Walked through at an intuition level, a modern handshake goes like this:

1. The client sends a ClientHello that lists the TLS versions, cipher suites, and key-exchange groups it supports, and in TLS 1.3 it already includes its key-exchange public value (a “key share”) to save a round trip.
2. The server picks a version and a group, sends back its own key share, and sends its certificate plus a digital signature over the handshake transcript. The certificate is how the server proves identity; the signature proves it holds the private key for that certificate.
3. Both sides combine their own private key-exchange value with the other side’s public one to compute the same shared secret, without that secret ever crossing the wire. This is the ECDHE step.
4. Each side runs that shared secret through a key-derivation function to produce the symmetric traffic keys.

The record protection phase is everything after the handshake. The application data gets encrypted and integrity-protected with the symmetric traffic keys, typically AES-GCM. No public-key math runs here. This phase is not the quantum problem.

So the crypto that quantum computing threatens is concentrated in the handshake: the key exchange in step 3, and the certificate signature in step 2. The record encryption in the second phase rides on symmetric keys, which are durable.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §2 (Protocol Overview), August 2018, datatracker.ietf.org.

Which parts of TLS are quantum-vulnerable?

Two of the three cryptographic roles in TLS are quantum-vulnerable, and they are vulnerable on very different clocks. This is the single most important thing to get right, because it’s what tells you what to fix first.

Key exchange is the urgent piece. Where TLS uses classical public-key key establishment, ephemeral ECDHE (including X25519), classical Diffie-Hellman, or the older RSA key-transport pattern, the shared secret can be recovered by Shor’s Algorithm on a large enough quantum computer.

The reason this is urgent is timing. An attacker can record encrypted TLS sessions today, store the ciphertext and the handshake, and decrypt it years later when a capable quantum computer exists. That’s harvest-now-decrypt-later, and it makes any TLS-protected data that must stay confidential for a long time exposed right now, well before the day the quantum computer boots up.

There’s a sharper edge on the older RSA key-transport cohort. Because RSA key transport has no forward secrecy, an attacker who records those sessions can decrypt all of them by compromising the server’s single long-term private key, with no quantum computer required at all. A 2026 study of real-world server configurations found 28.9% of TLS-enabled contexts still using RSA key exchange with no forward secrecy.

Certificate signatures are the slower track. TLS authentication relies on the server signing the handshake with an RSA or ECDSA key, and those signatures are also breakable by Shor’s Algorithm. But forging a signature requires a quantum computer at the moment of the connection, because a signature only matters live, during authentication. There’s nothing to harvest and no deferred payoff, so this is a Non-HNDL trust problem rather than a confidentiality problem. It still has to be fixed, but the clock is slower, which is why the standards and the ecosystem are moving key exchange first and signatures second.

Symmetric record protection survives. The AES encryption of the actual data isn’t broken by Shor’s algorithm. Its only quantum concern is Grover’s Algorithm, which speeds up brute-forcing a key but is defeated by using a larger key. AES-256 stays strong, so the data-plane of TLS is a strengthen-in-place item, not a replacement.

TLS role	The algorithm today	Quantum threat	Exposure class	Urgency
Key exchange	ECDHE / DH / RSA key transport	Broken by Shor’s	HNDL, harvestable today	Highest, migrate first
Certificate signature	RSA / ECDSA	Broken by Shor’s	Non-HNDL, needs a live CRQC	Slower track
Record encryption	AES-GCM	Weakened by Grover’s	Retain and strengthen	Use AES-256, no swap

Sources: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

Source: Balaji, H., Varshney, A., Ravi, P., Jain, S., Foe, R., Seet, J., Wang, H., Lam, K.-Y., and Chattopadhyay, A., “Operationalising Post-Quantum TLS,” arXiv:2605.17955, 2026, arxiv.org.

What’s the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 is a cleaner, faster, more secure redesign that removed the legacy options TLS 1.2 still allows, and that cleanup is also what makes it a better foundation for the post-quantum move. TLS 1.2 (RFC 5246, 2008) is still very widely deployed and still supports ephemeral key exchange when configured well, but it also permits older patterns that TLS 1.3 dropped entirely.

The differences that matter for the quantum transition:

1. Forward secrecy is mandatory in 1.3. TLS 1.3 removed static RSA and static Diffie-Hellman key exchange, so every 1.3 handshake uses ephemeral (EC)DHE and every session gets its own key. In TLS 1.2, RSA key transport with no forward secrecy is still a permitted (and still deployed) option, which is the worst starting point for HNDL.
2. The handshake is shorter. TLS 1.3 folds the key share into the ClientHello, cutting a round trip. That same ClientHello is where the oversized post-quantum key shares land, which is where a real deployment trap lives (see below).
3. The cipher-suite menu is smaller. TLS 1.3 trimmed the negotiable algorithms down to a short, modern list, which reduces the downgrade surface.
4. Post-quantum key exchange targets 1.3. The hybrid key-exchange standard is written for TLS 1.3, so the practical PQC path runs through 1.3, not 1.2.

Property	TLS 1.2 (RFC 5246)	TLS 1.3 (RFC 8446)
Published	August 2008	August 2018
Forward secrecy	Optional, RSA key transport still allowed	Mandatory, ephemeral (EC)DHE only
Round trips to set up	2	1
Legacy key exchange	Static RSA and static DH permitted	Removed
Post-quantum hybrid path	Not the target	The target version

Sources: T. Dierks, E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008, datatracker.ietf.org.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, datatracker.ietf.org: “Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.”

How does TLS go post-quantum?

TLS goes quantum-safe in two moves, and the ordering follows the two clocks from the vulnerability section: fix the harvestable key exchange first, fix the certificate signatures later.

Move one, hybrid key exchange. Instead of ripping out classical key exchange and hoping the new algorithm is perfect, TLS 1.3 runs a classical and a post-quantum key exchange together in the same handshake and mixes both results into the session secret. The standardized group is X25519MLKEM768, which combines classical X25519 with ML-KEM-768, NIST’s standardized lattice-based key-encapsulation mechanism.

The session is safe if either component holds. If ML-KEM turns out to have a flaw, X25519 still protects you against a classical attacker; if a quantum computer arrives, ML-KEM still protects you against it. This is the hybrid pattern, and it’s the defining move of the whole transition because it removes the HNDL exposure without betting everything on a young algorithm. The hybrid group is defined in the IETF draft for post-quantum ECDHE-MLKEM key agreement, which reached the RFC Editor queue in 2026 and is already deployed by major browsers and content networks.

Move two, post-quantum certificate signatures. The certificate side transitions later, toward NIST’s standardized signature schemes, ML-DSA as the general-purpose choice and SLH-DSA where a conservative hash-based signature is preferred. This is harder to roll out than key exchange because it touches the entire certificate ecosystem, certificate authorities, chain validation, every client that verifies a signature, so it moves on a longer timeline. During the overlap, composite certificates and parallel trust chains carry both a classical and a post-quantum signature so old and new clients can each validate what they understand.

The record-encryption layer needs no PQC move at all. Deployments keep strong symmetric protection (AES-256 with an authenticated mode), and that’s the future state.

Sources: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

Source: K. Kwiatkowski, P. Kampanakis, B. Westerbaan, D. Stebila, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” draft-ietf-tls-ecdhe-mlkem, X25519MLKEM768 codepoint 0x11EC (Recommended), RFC Editor queue 2026, datatracker.ietf.org.

What does migrating TLS actually look like?

Migrating TLS is a rollout problem tracked endpoint by endpoint, not a single switch, because of one rule that governs everything: a connection is only as quantum-safe as the weaker of its two endpoints. Both the client and the server have to support the hybrid group for a session to negotiate it, so the migration is really about getting the new group supported across a very large population of independent endpoints, many of them owned by vendors rather than by whoever owns the data.

The reality has a few defining features:

1. The weakest-endpoint rule. If a browser supports X25519MLKEM768 but the load balancer it connects to doesn’t, the handshake falls back to classical key exchange and the HNDL exposure stays open. One un-migrated reverse proxy, CDN edge, or legacy VPN gateway reopens the door for everything behind it. Coverage, not capability, is what closes the exposure.
2. The oversized ClientHello trap. A classical X25519 key share is 32 bytes. Adding ML-KEM-768 pushes the client’s key share past a kilobyte, and that larger ClientHello can spill across TCP packet boundaries. Some old middleboxes, load balancers, and firewalls were written assuming a ClientHello fits in a single packet and mishandle or drop the split message. This is the most-cited real interop failure of post-quantum TLS, and it’s why rollouts test the whole network path, including the middleboxes sitting between the endpoints.
3. Vendor-controlled surfaces gate the timeline. A large share of TLS termination happens on surfaces the enterprise doesn’t directly control, cloud load balancers, CDN edges, SaaS platforms, API gateways, managed service meshes. For those, support arrives when the provider ships it, so migration planning depends on vendor roadmaps as much as on internal work.
4. Visibility is harder than it looks. The presence of HTTPS tells you nothing about which key-exchange group or certificate algorithm a given endpoint actually uses, and network scanners that watch live handshakes miss what a configuration merely permits as a fallback. Seeing the real cryptographic posture takes configuration-level inspection, which is the evidence layer a cryptographic bill of materials is built to capture.

A useful proof point for the sequencing: a documented 2026 deployment introduced hybrid key exchange at the outermost TLS termination layer first (the public-facing web server and the API gateway) and propagated inward, reaching broad PQC coverage without changing the internal application, because TLS termination was decoupled from application logic. Outer-layer-first is a workable pattern when the termination point’s TLS stack supports a post-quantum provider.

The whole effort is a crypto-agility problem underneath, systems that can negotiate new key-exchange groups and certificate formats and retire old ones without a service outage migrate; systems hard-wired to one algorithm have to be re-architected first.

Source: Balaji, H., et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955, 2026, arxiv.org.

How urgent is the TLS migration?

TLS key exchange is one of the most time-sensitive items in the whole transition, and Mosca’s theorem is the clean way to see why. Mosca frames it as three numbers: X, how long the data must stay confidential; Y, how long the migration takes; and Z, how long until a capable quantum computer exists. If X plus Y is greater than Z, you’re already too late for that data. TLS protects enormous volumes of long-lived sensitive traffic, and migrating it across every endpoint and vendor is a multi-year Y, so for anything that must stay secret for a decade, the harvestable window is open now. That’s the argument for treating TLS key exchange as an early-phase target rather than a later cleanup.

The certificate side is genuinely less urgent, because it’s a live-authentication problem with nothing to harvest, so the honest prioritization is key exchange first, signatures on a longer runway.

Common misconceptions

• “We’re on TLS 1.3, so we’re quantum-safe.” TLS 1.3 fixed forward secrecy and cleaned up the handshake, but it still uses classical ECDHE by default. Quantum safety comes from negotiating a hybrid group like X25519MLKEM768, which is a separate deployment step on top of running 1.3.
• “TLS is broken by quantum computers.” The protocol isn’t broken. Two public-key pieces inside it (key exchange and certificate signatures) are, and the fix is to swap those mechanisms while keeping TLS. The symmetric encryption of the data is fine.
• “The certificate problem is the urgent one.” It’s the reverse. Certificate signatures need a quantum computer live at handshake time, so there’s nothing to harvest. Key exchange is harvestable today, which makes it the piece to migrate first.
• “HTTPS means the connection is future-safe.” HTTPS only tells you TLS is present, not which key-exchange group or certificate algorithm is in use. The visible padlock says nothing about quantum exposure.
• “Symmetric encryption needs replacing too.” It needs a larger key, not a new algorithm. AES-256 already provides a comfortable margin against Grover’s algorithm, so the data-plane is a strengthen-in-place item.
• “Enabling the hybrid group is a config flag and we’re done.” The flag is the easy part. A session only goes hybrid if both endpoints support the group, so the real work is coverage across every load balancer, CDN, gateway, and vendor surface in the path.

Questions people ask

What actually changes in TLS for post-quantum? The key-exchange step changes first, from classical ECDHE to a hybrid group (X25519MLKEM768) that runs classical X25519 and ML-KEM together. Certificate signatures change later, toward ML-DSA or SLH-DSA. The symmetric encryption of the data stays the same, just with AES-256.

Do I have to rewrite my application? Usually not. TLS is typically terminated by a web server, load balancer, or gateway, and post-quantum support comes from upgrading that TLS stack and its crypto provider, not from application code. That’s exactly why outer-layer-first rollouts work, the internal app can stay unchanged.

What’s hybrid key exchange, in one line? Running a classical and a post-quantum key exchange in the same handshake and mixing both into the session secret, so the session stays secure as long as either one holds. It’s the safety net that lets you adopt a young post-quantum algorithm without betting everything on it.

Is post-quantum TLS ready to deploy today? The hybrid key-exchange group X25519MLKEM768 is standardized (it reached the RFC Editor queue in 2026) and already shipping in major browsers, TLS libraries, and content-delivery networks. Post-quantum certificate signatures are further behind, still working through the certificate-authority and client-validation ecosystem.

What breaks in production when I turn on hybrid key exchange? The most common failure is the oversized ClientHello. The post-quantum key share pushes the client’s first message past a kilobyte so it spans multiple TCP packets, and some old middleboxes and load balancers drop or mishandle the split message. Testing the full network path, including the middleboxes in between, is what catches it.

Is hybrid key exchange backward compatible? Yes. Hybrid is negotiated, so a client that supports X25519MLKEM768 and a server that doesn’t will simply fall back to classical ECDHE, and the connection still works. That fallback is also the catch, because a fallback session is not quantum-safe, which is why coverage across endpoints is what actually closes the exposure.

Why migrate TLS before other protocols? Because TLS carries the largest volume of long-lived sensitive traffic and its key exchange is harvestable today. Under Mosca’s theorem, data that must stay confidential for years is already exposed, so TLS key exchange is a first-phase target rather than a later one.

Does RSA key exchange need a quantum computer to break? No, and that’s the sharp edge. RSA key transport has no forward secrecy, so recorded sessions can be decrypted by compromising the server’s one long-term private key, no quantum computer involved. Moving off static RSA to ephemeral (or hybrid) key exchange fixes a classical weakness and a quantum one at the same time.

---

Everything here is the map, given freely. When your team needs its own TLS estate found, its key-exchange and certificate exposure prioritized, and a hybrid rollout sequenced across every endpoint and vendor, defensible to your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.