How to Configure Post-Quantum Cryptography in Your Web Server

By Jaime Gómez García, Head of Quantum @ Santander.

Several browsers already support standard post-quantum cryptography (PQC) to provide long-term data confidentiality. However, setting up your web server to support PQC can still be a bit tricky. With the US government planning to use PQC by default on web services starting in 2025, now is a good time to start preparing by experimenting with your servers.

Two sides of PQC on web services

Let’s start by understanding how we use cryptography in web services. HTTPS is the secure version of HTTP. HTTPS relies on the Transport Layer Security protocol, which takes care of all the cryptography related tasks. You can learn more about TLS and how to discover its configurations here:

How to discover TLS configurations

TLS provides:

• Confidentiality: When a session starts, TLS negotiates a secret session key known only to the client and the server. This key is used to encrypt traffic using symmetric key algorithms like AES.
• Authentication: The server provides a certificate (its public key, signed by a certificate authority) that allows the browser to verify the server’s identity.

Currently, these features rely on public key cryptography algorithms, which are vulnerable to Cryptographically Relevant Quantum Computers (CRQC):

• Confidentiality relies on Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) key exchange.
• Authentication relies on RSA or ECDSA signature algorithms.

Of these two threats, confidentiality should be addressed first. Even though CRQCs do not exist yet, attackers can capture TLS sessions today and decrypt them later using a CRQC. This is known as the Harvest Now, Decrypt Later (HNDL) attack. If your data needs to remain confidential in the long term (e.g., 10–15 years), implementing additional protections today is essential.

On the other hand, authentication does not face immediate risk because server identity is verified interactively during a session. Future risks for authentication will primarily impact non-interactive use cases, such as document or software package signatures.

🎯 Summary

• Implement PQC key agreement now to protect long-term confidentiality.
• Post-quantum authentication can wait for now as it depends on evolving PQ certificate standards.

🔻 Classical key agreement

To get started, let’s examine key agreement in a default Apache setup.

I’m starting with a basic Apache server implementing HTTPS with the following TLS configuration (the default modern configuration should be similar):

SSLCiphersuite TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305
SSLProtocol -ALL +TLSv1.3 +TLSv1.2

The Client Hello

Using a modern web browser, check the TLS parameters negotiated in the Security tab of your browser’s developer tools. Here are the key details:

Ignore the certificate errors, as I’ve been using test certificates. The key details are highlighted in the red box:

• TLS version: TLSv1.3 (important since PQC is only supported from TLSv1.3).
• Key agreement: X25519 (an elliptic curve key exchange protocol).
• Encryption: AES_128_GCM.

To see the network traffic behind the scenes, use Wireshark and filter for the Client Hello and Server Hello messages:

tls.handshake.type == 1 || tls.handshake.type == 2

You may also add a filter for a single TCP stream.

In the Client Hello packet:

• Under supported groups, the browser offers:
• GREASE: Protects against poor TLS implementations.
• Unknown (0x11ec): This corresponds to X25519MLKEM768, a hybrid PQC algorithm combining X25519 (ECDH) with ML-KEM-768 (a PQC key encapsulation mechanism). It shows as Unknown because Wireshark still doesn’t know what 0x11ec means. In IANA Transport Layer Security (TLS) Parameters you can find that X25519MLKEM768 has been assigned the value 4588, which is 0x11ec in hexadecimal.
• X25519, secp256r1, and secp384r1: Various ECDH options.
• Under key_share, the browser includes data for both X25519 and X25519MLKEM768, with the latter adding about 1216 bytes.

Under the key_share extension we see our browser is advancing initial data for the X25519MLKEM768 (now shown as 4588) and X25519 groups just to save time. Note that by adding X25519MLKEM768 this section carries 1216 extra bytes of data. If I try with Edge on Android (which as I write this does not seem to support PQC), that section looks like this:

🎯 Summary

• Some modern browsers are already sending PQ key agreement data in advance hoping to find a PQ-enabled server to provide long-term confidentiality.

The Server Hello

In the server response, under key_share, you’ll see the server selecting X25519 and ignoring the PQC-supported group (X25519MLKEM768). This indicates that the server currently does not support or prefer post-quantum cryptography.

🎯 Summary

• Default webserver configurations do not support PQC yet.

🔻 Hybrid key agreement

Server-side setup

To enable PQC, we’ll enhance our OpenSSL installation using the Open Quantum Safe (OQS) provider. OpenSSL version 3.0 and above supports pluggable providers, allowing us to add PQC capabilities without altering the core installation.

Open Quantum Safe provider setup

Follow these steps (on Ubuntu), with help from an article in Linode:

1. Verify that you have openssl version 3.0 or above:

openssl version

2. Update packages:

sudo apt update
sudo apt install cmake libssl-dev ninja-build

3. Install oqs-provider:

git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
./scripts/fullbuild.sh
sudo cmake -- install _build

4. Run the tests provided. In my case all tests passed successfully:

./scripts/runtests.sh

5. Edit the openssl configuration to add the provider:

sudo vi /etc/ssl/openssl.cnf

6. Add the following lines at the end of the file

# PQC via OpenQuantumSafe
[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect
[default_sect]
activate = 1
[oqsprovider_sect]
activate = 1

7. Verify that openssl now shows the OQS provider:

openssl list -providers

8. See a list of key exchange algorithms your openssl installation supports:

openssl list -key-exchange-algorithms

9. See a list of key encapsulation mechanisms your openssl installation supports. Here you should see several PQC algorithms alone and in hybrid mode. You should have “X25519MLKEM768 @ oqsprovider” among others:

openssl list -kem-algorithm

🎉 Congratulations! Your openssl setup now supports several PQC algorithms. We will just focus on X25519MLKEM768 because we saw before that it is the only one currently supported by default by the major web browsers.

Apache configuration

Enable the X25519MLKEM768 group in Apache.

1. Edit the apache mod_ssl configuration:

sudo vi /etc/apache2/mods-enabled/ssl.conf

2. Add the following lines to specify which groups your server will support. You can play around adding or eliminating some. I, for instance, added support for X448 despite we have seen Chrome is not offering it:

# Configure key exchange and key encapsulation mechanisms
 SSLOpenSSLConfCmd Curves X25519MLKEM768:X448:X25519:prime256v1

3. Restart apache:

sudo systemctl restart apache2

Your server should now accept X25519MLKEM768.

Testing your quantum-safe TLS connections

Browse your test webpage and check the TLS parameters again. You should see:

The key agreement has changed from X25519 to X25519MLKEM768 and the confidentiality of the session will be safe while one of X25519 or MLKEM768 remains safe. Session confidentiality will only be at risk if both algorithms are compromised. Remember that the authentication, which depends on the certificates, remains quantum vulnerable.

To confirm in Wireshark, the Server Hello packet should now include 4588 (X25519MLKEM768) in the key_share extension. You can get more information at how the keys are being negotiated under the hood in TLS 1.3 Hybrid Key Exchange using X25519Kyber768 / ML-KEM.

The key_share length is now 1124 bytes, compared to 36 bytes of the X25519-only exchange. Note that the browsers are now sending larger Client Hellos hoping to find a server supporting X25519ML768. This extra information takes abo 1KB more data sent, and if the server supports the hybrid key exchange it will add another 1KB extra in the reply. Nowadays 1KB is of little concern in almost every use case, but if the contents included in the packets continue to grow they might hit the fragmentation issues described in Defending against future threats: Cloudflare goes post-quantum. Note that Client Hello is already larger than the typical TCP MSS size, so it is most likely being fragmented on the wire, despite Wireshark capturing on the host does not show it. It can also have a performance and/or bandwidth impact on web services receiving large volumes of traffic.

🎯 Summary

• The OQS provider can add PQC support for confidentiality to your Apache setup.

Conclusions

Now is the perfect time to start experimenting with quantum-safe TLS key agreement for long-term confidentiality.

Key takeaways include:

• Modern browsers already support the hybrid X25519MLKEM768 algorithm to provide quantum-safe confidentiality.
• The OQS provider can add PQC support to your OpenSSL setup, enabling quantum-safe configurations for servers like Apache and NGINX.
• Watch for performance impacts on large-scale websites.
• Note: At the time of writing, OQS provider version 0.7.0 may not be production-ready. Be sure to monitor updates to OpenSSL’s PQC integration roadmap.

Before you go:

Clap if you liked it 👏, comment and share this article to reach more community 🧞.

Would you like to be part of our technology project? Find our open vacancies worldwide here 👉 https://www.betechwithsantander.com/en/home