Oplon Secure Access 13.0.0 is out Update →

ARTICLE BLOG

Post-Quantum: Oplon Secure Access 13.0 Protects TLS 1.3 Traffic

Performance, Safety, and Operational Speed

The Post-Quantum era begins with Release 13.

Why Release 13 Is Important

With release 13.0.0, Oplon Secure Access negotiates a post-quantum hybrid key exchange by default on all TLS 1.3 connections it terminates or initiates. Encrypted traffic today remains protected even against a future adversary equipped with a quantum computer, without requiring any configuration changes and without losing compatibility with existing clients.

The threat is neither theoretical nor distant. In the “harvest now, decrypt later” scenario, an attacker records encrypted traffic today and stores it, waiting to decrypt it once they have a sufficiently powerful quantum computer. For those who manage identities, credentials, and sessions for government agencies, banks, and healthcare organizations, data in transit often holds value that lasts well beyond the time it would take to build a sufficiently powerful quantum computer.

The weak point: the key exchange

In TLS 1.3, the confidentiality of a session depends entirely on the ephemeral key exchange (ECDHE, typically using X25519 or P-256). The client and server derive a shared secret from which the symmetric keys used to encrypt all traffic are generated.

Shor’s algorithm, when run on a cryptographically relevant quantum computer, solves the discrete logarithm problem on elliptic curves in polynomial time. Anyone who has recorded the handshake can therefore reconstruct the shared secret and decrypt the entire session retroactively.

Symmetric encryption (AES-256-GCM, ChaCha20-Poly1305), on the other hand, remains robust: Grover’s algorithm at most halves its effective security margin. The risk that must be mitigated immediately is therefore the key exchange, not the encryption of the data.

Standards: ML-KEM

Our implementation is based on ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardized by NIST in 2024 as FIPS 203. Its security is based on the Module Learning With Errors problem, for which no efficient quantum algorithms are known.

ML-KEM is an encapsulation mechanism, not a Diffie-Hellman exchange. The client generates a key pair and sends the public key; the server encapsulates a random secret within it and returns the ciphertext; the client decapsulates it and obtains the same secret.

Parametro

Livello NIST

Chiave pubblica

Ciphertext

ML-KEM-768

3

1.184 byte

1.088 byte

ML-KEM-1024

5

1.568 byte

1.568 byte

How It Works in Oplon Secure Access 13

Oplon 13 implements the hybrid key exchange defined by the IETF in RFC 10024. The default preferred group is X25519MLKEM768, which combines ECDHE on X25519 with ML-KEM-768 into a single TLS 1.3 named group. The handshake takes place in a single round trip, just like a classic TLS 1.3 handshake:
    • In the ClientHello, the client sends a hybrid key share (1,216 bytes: 1,184 bytes of the ML-KEM public key plus 32 bytes of the X25519 public key) along with a traditional X25519 key share.
    • If the peer also supports the hybrid key schedule, the ServerHello returns the ML-KEM ciphertext and the server’s X25519 public key (1,120 bytes total).
    • Both parties compute the two secrets and concatenate them as input to the TLS 1.3 key schedule.

hybrid secret = ML-KEM secret || X25519 secret

The principle is simple: the session remains secure as long as at least one of the two algorithms remains unbroken. X25519 guarantees security—already proven in the field—against classical attacks; ML-KEM adds resistance to quantum attacks. This protection applies to all segments where Oplon terminates or initiates a TLS 1.3 connection:
  • Client → Application Delivery Controller / reverse proxy: browser and application connections to on-premises Oplon nodes.
  • Application Delivery Controller → backend services: when Oplon forwards traffic to TLS-secured applications.

Compatibility and Negotiation

No existing client stops working: the hybrid group is only the first in the preference list, not the only one. The result depends on the peer:

Peer

Esito della negoziazione

Supporta X25519MLKEM768 (browser moderni, librerie TLS aggiornate)

Sessione ibrida post-quantum

Supporta solo TLS 1.3 classico

Fallback trasparente su X25519

Supporta solo TLS 1.2

Sessione classica TLS 1.2: lo scambio ibrido è definito solo per TLS 1.3

The overhead is minimal: about 1.1 KB more per direction during the handshake and a computational cost for ML-KEM comparable to that of X25519. There is no impact on already established sessions, because the symmetric encryption remains unchanged.

A note for those with intermediate devices: the protection applies to the segment where Oplon terminates TLS. If there is a load balancer, WAF, or proxy in front of the Oplon nodes that terminates the connection, that device determines the key exchange with the client. Furthermore, some older middleboxes do not handle ClientHello messages larger than a single packet properly.

What Remains a Classic, right Now

Release 13 protects the confidentiality of sessions—that is, the risk that must be mitigated immediately. The authentication of the server during the handshake continues to rely on RSA or ECDSA certificates. This decision is consistent with the current state of the ecosystem. An attack on the signature requires a quantum computer to be available at the time of the handshake, not afterward: traffic recorded today does not become vulnerable because of the certificates. Furthermore, the use of ML-DSA (FIPS 204) in TLS certificates still requires support from CAs, browsers, and clients. We will continue to monitor the evolution of IETF standards and integrate post-quantum signatures as the ecosystem makes them ready for production use.

Next Steps for Oplon Secure Access Users

To enable protection, simply update the nodes to release 13.0.0: hybrid support is enabled by default. To verify this and get the most out of it:

  • Update your on-premises nodes to 13.0.0.
  • Verify the result: in recent browsers, the developer tools (Security tab) show X25519MLKEM768 as the connection’s key exchange.
  • Identify the devices that terminate TLS connections in front of Oplon (load balancers, WAFs) and verify their support for hybrid groups.
  • If you want to extend protection to the internal segment as well, verify that backend services accept TLS 1.3.
  • Record the change in the organization’s cryptographic inventory.

With Oplon, it’s easy to verify which cryptographic algorithms your infrastructure actually uses. For each connection, Oplon logs the protocol version and the key exchange algorithm negotiated by the client and server during the handshake, on both the client side and the backend side.

This data immediately reveals which applications still use outdated protocols or algorithms, such as TLS 1.0, 1.1, or 1.2, or rely solely on a classic key exchange. This allows for targeted planning of updates: at least to TLS 1.3 as a first step, or directly to post-quantum hybrid key exchange. The same data feeds the cryptographic inventory with evidence collected from real-world traffic.

This last point is no minor detail. The EU’s coordinated roadmap for the transition to post-quantum cryptography, developed by the NIS Cooperation Group, calls for cryptographic inventories and transition plans by the end of 2026 and the migration of high-risk use cases by 2030, including healthcare and finance. For those operating under NIS2 and ISO/IEC 27001:2022, adopting hybrid key exchange today is a concrete and documentable step in that direction.

Summary

Oplon Secure Access 13 makes the key exchange for every TLS 1.3 connection it manages post-quantum by default, without sacrificing compatibility. This is the first step on a path that will follow industry standards as they evolve, starting with digital signatures.

For more information, please fill out the form in the Contact section.

Voucher Cloud & Cybersecurity

The MIMIT Cloud & Cybersecurity Voucher offers small and medium-sized enterprises (SMEs) and self-employed individuals a concrete opportunity to invest in the security and evolution of their IT infrastructure.

Leggi di più→

Oplon Secure Access 12.3.0

Oplon Secure Access 12.3.0 introduces enhancements designed to make remote access management even more efficient, secure, and simple. The new release offers improved Remote Desktop session quality thanks to Sharp Mode, more advanced password rotation control with the new Password Rotation Test Runner, and the ability to create Temporary Connections

Leggi di più→

Latest news from the blog

Voucher Cloud & Cybersecurity

The MIMIT Cloud & Cybersecurity Voucher offers small and medium-sized enterprises (SMEs) and self-employed individuals a concrete opportunity to invest in the security and evolution of their IT infrastructure.

Leggi di più→

Oplon Secure Access 12.3.0

Oplon Secure Access 12.3.0 introduces enhancements designed to make remote access management even more efficient, secure, and simple. The new release offers improved Remote Desktop session quality thanks to Sharp Mode, more advanced password rotation control with the new Password Rotation Test Runner, and the ability to create Temporary Connections

Leggi di più→

DDoS, Click Day, and Application Outages

Click Days are no longer about attacks, but synchronized legitimate demand that can collapse systems. Traditional WAFs fail: they protect the network, not backend capacity. Resilience requires managing real application capacity under extreme load.

Leggi di più→
.st0 { fill: #ec6b4f; }

Request a demo

Fill out the form to be contacted by one of our operators. 

Scopri il Partner Program

Compila il form per ricevere una mail contenente il link che ti permetterà di scaricare il Partner Program in formato PDF.