Your TLS Key Exchange

This connection uses X25519MLKEM768, a hybrid post-quantum key exchange.

This page shows the TLS group negotiated for the current browser connection and then explains what that result actually means.

Load each port from your browser and compare. If you also run Wireshark on the client, the TLS ClientHello and ServerHello will show the same key exchange group listed above.

The two endpoints of this lab

The demo intentionally serves the same PHP page over two different TLS front doors so you can compare the handshake side by side:

• Port 443 — post-quantum path. Your browser terminates TLS against the cluster gateway, which negotiates the hybrid X25519MLKEM768 key exchange with modern browsers (Chrome 131+ and other browsers that have hybrid PQ TLS enabled). The request is then forwarded to this backend over an internal TLS hop that also supports MLKEM, so the value above should read X25519MLKEM768.
• Port 8443 — classical path. Your browser talks TLS directly to this VM's nginx on port 8443, where an ssl_conf_command Groups directive only advertises the classical curves X25519, P-256, and P-384. No post-quantum group is offered, so the handshake falls back to plain X25519. That fallback is what a non-PQ TLS handshake looks like today.

Same server, same certificate, same PHP code — only the TLS profile of the listener changes. If you run Wireshark on the client, the packets on port 443 carry a much larger key_share extension (MLKEM public keys are ~1kB) than the packets on port 8443 (X25519 is 32 bytes). That size difference is the visible fingerprint of the post-quantum handshake.

What This Check Is Showing

This page is not saying that the certificate alone is post-quantum secure. It is showing the key exchange negotiated for the current TLS session.

A TLS connection has two different security pieces:

• The certificate and its private key authenticate the server identity.
• The key exchange creates the temporary session key that encrypts the connection.

That distinction matters. The certificate proves you are talking to the right server, but the session's post-quantum property comes mainly from the key exchange, not from the certificate by itself.

Why Sniffed Traffic Is Still Protected

An attacker can capture the TLS handshake messages and the encrypted traffic. The public key_share values are visible on the wire, but the actual session key never is — the client and server each derive it locally from the shares plus their own private material.

The concern with future attacks is often called harvest now, decrypt later:

• someone records encrypted traffic today,
• cannot read it immediately,
• and later tries to break the original key exchange with stronger computing power.

That is where a post-quantum or hybrid key exchange matters. The goal is that seeing the handshake should still not be enough to reconstruct the session key later.

What Post-Quantum Does Not Protect

Post-quantum TLS does not protect against endpoint compromise. If an attacker steals the live session key from browser or server memory, the session is already compromised. In that case, no quantum attack is needed.

So the security model is:

• certificate + private key: server identity
• key exchange: session confidentiality
• post-quantum protection: resistance against future attacks on the handshake
• endpoint security: still critical

Interactive Toy DH + Simulated Discrete-Log Attack

This is a teaching toy, not real security. It uses tiny numbers so you can see how a shared secret is created, what an attacker can sniff, and how a brute-force discrete-log attack would recover the private value in a breakable toy example. In a real system with big numbers, that discrete-log problem is what Shor's quantum algorithm would attack — here we just search all candidates because the field is tiny.

The attacker does not receive the shared secret directly. In this toy demo, they recover Alice's private value from the public handshake because the numbers are tiny. That is the intuition behind why a powerful quantum attack matters for discrete-log style systems.

Toy Post-Quantum Intuition

Lattice-based schemes do not hide a secret scalar the same way elliptic-curve Diffie-Hellman does. Instead, they rely on a different kind of hard problem built from vectors, matrices, and structured noise.

This does not mean lattice-based cryptography is proven unbreakable. It means that, unlike factoring and discrete-log systems, we do not currently know a quantum attack of the same kind of impact.

Shor threatens public-key systems based on factoring and discrete logarithms, while Grover mainly affects brute-force search and symmetric-key sizing.

Why The Post-Quantum Path Is Different

The post-quantum path is still trying to achieve the same goal: client and server end up with a shared session key without sending that key directly over the network.

The difference is that it does not rely only on the same classical math family as elliptic-curve Diffie-Hellman. In a hybrid result like X25519MLKEM768, one part is classical, and one part comes from a post-quantum construction.

So the practical point is not that one connection is encrypted and the other is not. Both are encrypted. The point is that if an attacker records the handshake today and tries to break it later, the hybrid path forces them to deal with more than just the classical part.

This is why the page says the hybrid path is better protected against future quantum attacks on the handshake.

Where to read the theory behind this

Post-quantum cryptography is a wide topic. Beyond the TLS handshake shown here, it touches how keys are generated, stored in HSMs, rotated across cloud KMS, embedded in PKI hierarchies, and how organizations should plan a migration that spans years and many protocols.

The Cloud Security Alliance published a paper that covers that broader picture in depth — key lifecycle, HSM/KMS readiness, hybrid schemes, downgrade risk, MTU/fragmentation concerns for larger keys, and a phased migration roadmap:

Post-Quantum Cryptography Key Management — Cloud Security Alliance

This lab is a small, practical companion to that reading. It shows one concrete slice of the transition made tangible in a browser: what a hybrid post-quantum TLS handshake actually looks like on port 443, what the classical fallback looks like on port 8443, and how the size of the key_share extension changes between the two. It is meant to make the abstract concept less abstract, not to replace the paper.