Verify post-quantum key exchange
Check that TLS 1.3 connections to your domain negotiate the X25519MLKEM768 post-quantum hybrid key exchange, from a browser or with OpenSSL.
You can check from a browser or with OpenSSL that the connections to a domain served through Azion use post-quantum key exchange. Azion negotiates post-quantum cryptography (PQC) on every TLS 1.3 connection without any configuration: no certificate change, no setting, and no change to your application. To choose the TLS versions and ciphers a workload accepts, refer to Set the TLS cipher suite.
Prerequisites
- A domain served through a workload.
- For the browser check, a browser that supports ML-KEM: Chrome 131 or later, Edge 131 or later, Firefox 135 or later, or a recent Safari version.
- For the command-line checks, OpenSSL.
Check the key exchange in a browser
A browser that supports ML-KEM negotiates the hybrid algorithm on its own when it connects to a domain served through Azion.
To check the key exchange in the browser:
- Open your domain in the browser.
- Open the developer tools with F12.
- Select the Security tab.
The Key Exchange field shows X25519MLKEM768.
Check the key exchange with OpenSSL
The command opens a TLS 1.3 connection to your domain and prints the group that the connection negotiated. Replace your-domain.com with your domain:
The output names the post-quantum hybrid group:
Check the classical fallback
A client without PQC support falls back to a classical algorithm, and Azion accepts the connection. The command offers only the classical group X25519, the way such a client does:
The output names the classical group:
The connection succeeds without the post-quantum layer.
Key exchange on Azion
Azion negotiates PQC on the path from the client to Azion. Its TLS libraries support the algorithm that NIST standardized in FIPS 203, ML-KEM.
The hybrid model
The negotiated group, X25519MLKEM768, combines two layers. If one layer is broken, the other still protects the session, so the connection is as secure as the stronger of the two.
| Layer | Algorithm | What it does |
|---|---|---|
| Classical | X25519 | Elliptic curve cryptography, tested and secure against conventional adversaries |
| Post-quantum | ML-KEM-768 | The algorithm NIST standardized in FIPS 203, resistant to attacks from quantum computers |
PQC protects the key exchange against “harvest now, decrypt later”: an adversary records encrypted traffic today and decrypts it once quantum computers exist. A post-quantum key exchange keeps that recorded traffic unreadable.
Priority order
Azion offers the key exchange groups in this order:
| Priority | Algorithm | Type |
|---|---|---|
| 1 | X25519MLKEM768 | Post-quantum hybrid |
| 2 | X25519 | Classical, elliptic curve |
| 3 | P-256 (secp256r1) | Classical, NIST curve |
| 4 | X448 | Classical, elliptic curve |
| 5 | P-384 (secp384r1) | Classical, NIST curve |
X25519MLKEM768 comes first because mainstream browsers send a key share for that group by default in their ClientHello. With another group first, such as SecP256r1MLKEM768, the server would answer with a HelloRetryRequest. That adds a full round trip to every new connection.
Compatibility
- A client that supports PQC negotiates X25519MLKEM768.
- A client without PQC support falls back to X25519 or P-256.
- Azion refuses no connection over the key exchange. The server accepts the best algorithm that both sides support.
PQC exists only in TLS 1.3, because TLS 1.2 and earlier versions have no ML-KEM key exchange. A workload can accept TLS 1.2 as its minimum version and still accept TLS 1.3. With that setting, only the TLS 1.3 connections are protected with PQC. A TLS 1.2 connection uses the cipher suite configured for the workload.
Connections to the origin
On the path from an application to its origin, Azion negotiates PQC when the origin server accepts TLS 1.3 with X25519MLKEM768. An origin without PQC support gets a classical key exchange. Connections from Functions to an origin do not negotiate PQC.
Certificates
TLS certificates stay RSA or ECDSA, because public certificate authorities do not issue post-quantum certificates. A certificate protects against an active adversary with a quantum computer at the time of the connection, and no such computer exists today. The key exchange protects against the recording of traffic today, which is why it comes first.