Concrete Technical Steps for Post-Quantum TLS, SSH, and IPsec

The arrival of Cryptographically Relevant Quantum Computers (CRQC) is not a distant singularity; for security architects, it is an immediate data governance crisis. The threat of “Store-Now-Decrypt-Later” (SNDL) means that long-term sensitive data encrypted today intellectual property, health records, state secrets is already vulnerable if it traverses a network protected only by classical algorithms like RSA or Elliptic Curves.

The French National Cybersecurity Agency (ANSSI) has recently published detailed technical guidance for transitioning the internet’s core protocols TLS, SSH, and IPsec to a quantum-safe state. Their verdict is clear: we cannot wait for “pure” post-quantum algorithms to mature. We must adopt Hybridization immediately. This strategy combines the battle-tested reliability of classical cryptography with the theoretical resistance of new Post-Quantum (PQ) algorithms, ensuring that if one fails, the other holds the line.

This guide relies on the ANSSI’s technical sheets into a concrete engineering roadmap. We will strip away the academic theory and focus on the specific configuration changes, version upgrades, and architectural shifts required to secure your data in transit against the quantum threat.

What to Remember

• Hybridization is Non-Negotiable: Do not replace classical algorithms; augment them. Combine ECDH with ML-KEM to protect against both current and future threats.
• Prioritize Confidentiality over Authentication: The immediate risk is retro-decryption (SNDL). Focus on upgrading Key Exchange (KEX) mechanisms now; Authentication (Signatures) can wait for mature standards.
• The “Packet Bloat” Problem: Post-quantum keys are massive. You must tune network MTUs and enable fragmentation handling (especially for IPsec/UDP) to prevent silent drops.
• Protocol Specifics Matter: TLS 1.3 supports native Pre-Shared Keys (PSK) for a quick fix; SSHv2 does not. IPsec requires specific RFC implementations (IKE_INTERMEDIATE) to handle large hybrid payloads.
• Inventory First: You cannot migrate what you cannot see. Scan your infrastructure for legacy OpenSSH versions and outdated VPN concentrators immediately.

1. TLS 1.3: Securing the Web and API Traffic

Transport Layer Security (TLS) 1.3 is the backbone of secure web communication. The primary risk resides in the Handshake protocol, specifically the key exchange mechanisms.

5 Concrete Technical Actions for TLS 1.3

1. Implement Hybrid Key Exchange (KEX) Immediately Do not switch to pure Post-Quantum algorithms yet. You must configure your servers to accept Hybrid KEX.

   • Technical Detail: Look for implementations supporting the X25519Kyber768Draft00 (or similar standardized ML-KEM combinations). In OpenSSL 3.5+, ensure your configuration allows groups that combine ECDHE with ML-KEM. This ensures that even if the quantum math has a hidden flaw, the classical curve protects you.

2. Prepare for “ClientHello” Bloat and Fragmentation Post-quantum keys are significantly larger than classical ECC keys.

   • Technical Detail: A standard ECDH key share is small (~32 bytes). A Kyber-768 key share is much larger (~1KB+). This increases the size of the ClientHello message. Ensure your load balancers, firewalls, and middleboxes are configured to handle large handshake packets and do not drop packets that exceed typical MTU sizes or require TCP fragmentation.

3. Use Pre-Shared Keys (PSK) for Internal Critical Flows If you control both the client and server (e.g., internal microservices), ANSSI notes that TLS 1.3 natively supports Pre-Shared Keys for key derivation.

   • Technical Detail: Configure PSK ciphersuites. While this provides quantum resistance for confidentiality, be aware of the Perfect Forward Secrecy (PFS) trade-off. If the static PSK is compromised later by a quantum computer, all past sessions recorded by an attacker are compromised. Use this only with frequent key rotation.

4. Delay Implementation of Hybrid Certificates (Auth) While Key Exchange requires immediate action to stop SNDL attacks, Authentication (Signatures) is less urgent because an attacker needs a quantum computer live during the handshake to forge a signature.

   • Technical Detail: There is currently no finalized standard for hybrid certificates (e.g., X.509 certificates containing both RSA and ML-DSA keys). Do not roll your own custom PKI for this yet. Wait for the IETF drafts (like draft-ietf-tls-mldsa) to mature.

5. Monitor OpenSSL and Browser Support Implementation support is fragmented.

   • Technical Detail: Chrome has already begun supporting hybrid Kyber KEM. Ensure your backend libraries (like OpenSSL, BoringSSL, or WolfSSL) are updated. OpenSSL 3.2+ and specifically 3.5.0 are critical targets for roadmap planning as they introduce native support for the algorithms referenced in the ANSSI docs (ML-KEM, SLH-DSA).

2. SSHv2: Hardening Administration Access

Secure Shell (SSH) is critical for infrastructure management. Like TLS, the handshake and user authentication phases are vulnerable. However, unlike TLS, SSH does not natively support Pre-Shared Keys for transport encryption, so Hybridization is the only viable path.

5 Concrete Technical Actions for SSHv2

1. Upgrade to OpenSSH 9.9+ or 10.0 The fastest way to achieve PQC security is via client/server updates. OpenSSH is the de facto standard and is moving quickly.

   • Technical Detail: OpenSSH 9.0 introduced sntrup761x25519-sha512. OpenSSH 10.0 defaults to ML-KEM hybridization. Audit your fleet and deprecate old SSH binaries (e.g., Dropbear or old OpenSSH versions) that lack hybrid KEX support.

2. Enforce Hybrid Key Exchange Algorithms in sshd_config Do not rely on defaults negotiation; force the issue for high-security zones.

   • Technical Detail: In your /etc/ssh/sshd_config, explicitly set your Key Exchange Algorithms:

     KexAlgorithms [email protected],ecdh-sha2-nistp521

     This hybrid algorithm (Streamlined NTRU Prime + X25519) is robust and currently recommended until ML-KEM becomes the global default.

3. Do Not Attempt PSK Workarounds ANSSI explicitly states that SSHv2 does not support PSK for the transport layer.

   • Technical Detail: Do not try to wrap SSH in other tunnels just to get PSK protection, as it adds complexity and points of failure. Focus strictly on the Hybrid Key Exchange upgrades within the protocol itself.

4. Prepare for Hybrid User Authentication While less urgent than KEX, you will eventually need to update host keys and user keys.

   • Technical Detail: Watch for support for ssh-mldsa or hybrid certificates in OpenSSH. When available, you will need to rotate not just authorized_keys files, but also the ssh_host_keys on every server. Automate your key rotation capabilities now (e.g., using Ansible or HashiCorp Vault) so you are ready to swap thousands of keys when the standards finalize.

5. Segment Management Networks Since SSH PQC is still evolving, network segmentation remains your strongest quantum-mitigation control.

   • Technical Detail: If an attacker cannot reach port 22, they cannot capture the handshake for future quantum decryption. Use VPNs (ideally PQC-secured IPSec) to wrap SSH traffic, adding a layer of defense-in-depth.

3. IPsec (IKEv2): Protecting Network Tunnels

IPsec is complex because it involves the IKEv2 handshake (UDP-based) and the ESP data plane. The data plane uses symmetric crypto (AES), which is safe (provided keys are 256-bit). The vulnerability lies in IKEv2 key derivation.

5 Concrete Technical Actions for IPsec

1. Enable IKEv2 Fragmentation (RFC 7383) This is the single most critical configuration change for PQC IPsec.

   • Technical Detail: Post-Quantum keys and signatures are massive. Because IKEv2 uses UDP, large packets will be fragmented. Many firewalls drop IP fragments (Denial of Service risk). You must enable RFC 7383 IKEv2 Fragmentation on your VPN concentrators (e.g., StrongSwan). This allows IKE itself to handle the splitting of messages logically, rather than relying on the unreliable IP layer fragmentation.

2. Implement RFC 8784 (Post-Quantum Preshared Keys) If you need quantum resistance today, this is the standard-compliant way to do it before full hybrid KEX is ready.

   • Technical Detail: RFC 8784 allows you to mix a pre-shared key (PPK) into the key derivation of an IKE SA. This ensures that even if the Diffie-Hellman exchange is broken by a quantum computer, the session keys remain secure provided the PPK was shared securely (out of band). StrongSwan 5.7.0+ supports this.

3. Utilize IKE_INTERMEDIATE for Hybrid KEX You cannot fit Hybrid keys into the standard IKE_SA_INIT packet without breaking things.

   • Technical Detail: Configure your IPsec stack to support RFC 9242 (IKE_INTERMEDIATE). This creates a new exchange stage specifically designed to transfer large data blobs (like ML-KEM public keys) before authentication happens. This is a prerequisite for RFC 9370 (Multiple Key Exchanges).

4. Upgrade to StrongSwan 6.0+ StrongSwan is the reference implementation for many Linux-based VPNs.

   • Technical Detail: StrongSwan 6.0 implements the modern “Multiple Key Exchanges” (RFC 9370) necessary for proper hybridization. Older versions may require complex patching or unstable plugins to achieve PQC.

5. Adjust MTU and MSS Due to the overhead of PQC headers and potential fragmentation handling, the effective payload size inside the tunnel decreases.

   • Technical Detail: Be conservative with your Maximum Transmission Unit (MTU) and Maximum Segment Size (MSS) clamping. If you add hybrid certificates and hybrid KEX, the handshake overhead grows. Test your VPNs specifically for packet loss on large file transfers during the handshake phase to ensure the new PQC payloads aren’t causing silent drops.

Conclusion: Crypto-Agility is the New Standard

The transition to Post-Quantum Cryptography is not a simple “patch Tuesday” update. It is a fundamental re-engineering of our cryptographic trust layer. The guidance from ANSSI highlights that while the mathematics are complex, the engineering challenges packet fragmentation, backwards compatibility, and performance overhead are equally critical.

We are entering an era of Crypto-Agility. Hardcoded algorithms are a liability. Your infrastructure must be designed to swap cryptographic primitives as easily as you rotate passwords. By implementing Hybrid Key Exchanges today and preparing your network for larger payloads, you are not just ticking a compliance box; you are immunizing your organization’s history against the future. The quantum clock is ticking, but with these steps, you can ensure your data remains a secret, no matter how powerful the computer trying to crack it becomes.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

Frequently Asked Questions (FAQ)

What is 'Store-Now-Decrypt-Later' (SNDL)?

SNDL is a strategy where attackers intercept and store encrypted data today, waiting for powerful quantum computers to become available in the future to decrypt it.

Why is Hybridization recommended over pure PQC?

Hybridization combines a classical algorithm (like ECDH) with a Post-Quantum one (like ML-KEM). This ensures security even if the new PQ algorithm is found to have a flaw, as the classical one remains unbroken by classical computers.

Does SSHv2 support Pre-Shared Keys for transport encryption?

No, ANSSI explicitly notes that SSHv2 does not natively support PSK for transport layer confidentiality. Hybrid Key Exchange is the primary migration path for SSH.

What is the biggest network challenge with PQC IPsec?

Packet fragmentation. PQC keys are large, causing UDP packets to exceed the MTU. Enabling `IKEv2 Fragmentation` (RFC 7383) is critical to prevent dropped packets.

Which OpenSSH version should I target for PQC support?

You should target OpenSSH 9.9+ or preferably 10.0, as these versions include robust support for hybrid key exchange algorithms like `sntrup761x25519-sha512` and ML-KEM.

Resources

• ANSSI Technical Guidance: Official ANSSI Publications on Post-Quantum Migration
• OpenSSH Release Notes: OpenSSH Project
• StrongSwan Documentation: Post-Quantum Key Exchange in StrongSwan
• RFC 9370: Multiple Key Exchanges in IKEv2
• NIST PQC Standardization: NIST Post-Quantum Cryptography Program