How to verify that your setup is ready for post-quantum cryptography

This entry assumes familiarity with basic PQC concepts. If you want the background information, start with Part 1.

The TLS 1.3 handshake with hybrid ML-KEM

TLS 1.3 is the protocol that protects the vast majority of HTTPS traffic today. Unlike TLS 1.2, it reduces the number of handshake round-trips and eliminates several legacy mechanisms that were a source of vulnerabilities. The basic handshake works like this:

1. The client sends a ClientHello with the algorithms it supports and an ephemeral public key (key share).
2. The server responds with a ServerHello, selecting the cryptographic parameters, its own key share, and the signed certificate.
3. Both parties derive the shared secret from the exchanged key shares.
4. This secret generates the session keys that will encrypt the traffic.

The critical point from a PQC perspective lies in the key agreement step. With a hybrid model, the client and server exchange ML-KEM key shares along with those of classic ECDHE. The session key is derived from the most secure algorithm supported by the client. Today, most TLS traffic already travels with ML-KEM active, driven by native support in Chrome, Firefox y Edge , while maintaining traditional ML-KEM to ensure compatibility with older devices. This hybrid approach is the one the industry has adopted because it doesn’t degrade existing security while adding quantum resilience.

Performance and impact on the network

Regarding the network impact, the adoption of PQC results in a slight increase in packet size during the initial key exchange. However, performance tests indicate that for most web applications and content sites, the latency impact is minimal and is offset by the optimization of TLS 1.3 and the near-user termination offered by content delivery networks.

ML-KEM key shares add between 1 and 2 KB to the TLS handshake compared to pure ECDHE. This is marginal for connections of normal duration. It may be more noticeable in environments with a high volume of very short TLS connections or with bandwidth constraints.

The greatest potential impact lies not in the key agreement itself, but in post-quantum certificates. ML-DSA or SLH-DSA-based certificates can be 10 to 50 times larger than current ECDSA-based certificates, with direct implications for handshake size and intermediate network devices that inspect TLS traffic. This is precisely why the industry has prioritized migrating from the key agreement: the performance cost is low, and the gains compared to HNDL (Harvest Now, Decrypt Later) are immediate.

CDNs, with their distributed network, have a structural advantage since they terminate TLS close to the end user, which absorbs much of the additional latency of the handshake regardless of the size of the packets exchanged.

How to verify that your origin server is ready for the post-quantum key agreement

For those technical teams who wish to verify their readiness, there are tools available to check if the origin server is correctly configured for the post-quantum key agreement.

The first step is to confirm that your server is negotiating TLS 1.3. ML-KEM is only available on TLS 1.3; if the server drops to TLS 1.2, PQC support is not possible on that bandwidth.

To check what key groups your server is offering you can use OpenSSL from the command line:

openssl s_client -connect tu-servidor.com:443 -tls1_3

In the output, look for references to X25519MLKEM768 or SecP256r1MLKEM768. These are the most common hybrid ML-KEM groups in current implementations. If they don’t appear, the server isn’t offering PQC support in the key agreement.

Other options: Qualys’ SSL Labs Server Test includes information on post-quantum group support in its latest versions. In Chrome, you can check the key_exchange_group field at chrome://net-internals/#events during an active TLS connection.

Recommendations

Include PQC support as a requirement in any procurement process for CDN, WAF, or TLS service providers. If a provider doesn’t have a clear position on their migration roadmap, that’s relevant information for your decision.

Also:

• Automate the issuance and renewal of certificates. Agility in certificate management is a prerequisite for migrating to post-quantum certificates when the ecosystem is ready, and it’s a practice that reduces operational risks regardless of quantum computing.
• Disable TLS 1.1 and TLS 1.2 where possible. These versions do not use PQC algorithms and unnecessarily expand the attack surface.
• Evaluate critical suppliers well in advance. If a supplier fails to transition to PQC, the impact can be significant. It’s best to identify these risks before they become critical.

For data with a long lifespan, consider that the HNDL exposure window is already open if that traffic is not protected with PQC. The time to act is not when quantum computers arrive, but before they arrive.

Transparent Edge already secures communication between browsers and edge nodes using post-quantum encryption. We’re protecting your future now. Contact our customer support department for more information.