--- name: azion-verify-post-quantum-key-exchange description: >- Check that TLS 1.3 connections to your domain negotiate the X25519MLKEM768 post-quantum hybrid key exchange, from a browser or with OpenSSL. --- # Verify post-quantum key exchange 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](/en/documentation/guides/application-security/tls-and-certificates/ciphers/). --- ## Prerequisites - A domain served through a [workload](/en/documentation/platform/workloads/). - 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: 1. Open your domain in the browser. 2. Open the developer tools with **F12**. 3. 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: ```bash echo "Q" | openssl s_client -connect your-domain.com:443 -tls1_3 2>&1 | grep "group" ``` The output names the post-quantum hybrid group: ```text Negotiated TLS1.3 group: X25519MLKEM768 ``` --- ## 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: ```bash echo "Q" | openssl s_client -connect your-domain.com:443 -tls1_3 -groups X25519 2>&1 | grep "group" ``` The output names the classical group: ```text Negotiated TLS1.3 group: X25519 ``` 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. --- ## Next steps - [Set the TLS cipher suite](/en/documentation/guides/application-security/tls-and-certificates/ciphers.md): Set the minimum TLS version and the ciphers a workload accepts. - [Create a digital certificate](/en/documentation/guides/application-security/tls-and-certificates/create-a-digital-certificate.md): Add the RSA or ECDSA certificate that a workload serves. - [mTLS](/en/documentation/platform/workloads/mtls.md): Require client certificates on the connections to a workload. - [Workloads](/en/documentation/platform/workloads.md): Read how a workload receives TLS connections for your domains.