Quantum-Safe Local Tunnels: Preparing Your Development Stack for Post-Quantum Cryptography

Quantum computing is a roadmap item for security teams and standards bodies. NIST has proposed a date for retiring today’s public-key algorithms, and major CDNs and operating systems already negotiate post-quantum key exchange by default. One part of the stack gets little attention in this migration: the local development tunnel.

Developers use tunnels to expose localhost to webhook providers, mobile test devices, and clients reviewing a staging build. A tunnel is a TLS-protected pipe, so it inherits the same cryptographic exposure as any other TLS connection. It also often carries material you would not want read later, such as API keys, session tokens, and payloads copied from real systems.

This guide covers what a quantum computer would break in a tunnel and what it would not. It also covers what the standards say today and how hybrid key exchange works in TLS 1.3. It then looks at which tunneling tools already support post-quantum key exchange and what the measured performance cost is.

---

1. What is actually at risk in a tunnel

The anatomy of a tunnel connection

A tunnel has two legs:

1. Public leg: a browser, mobile app, or webhook sender connects over TLS to the tunnel provider’s public edge.
2. Agent leg: a client daemon on your laptop keeps a long-lived outbound connection to the same edge, and requests are multiplexed back down it.

Each leg is protected by its own cryptographic handshake. In TLS 1.3, the session keys come from an ephemeral (EC)DHE key exchange, usually X25519. The server’s certificate is verified with a signature such as RSA or ECDSA. A tunnel that protects only one of these legs leaves the other classical. Either leg can be the weak one.

Why Shor’s algorithm matters here

Shor’s algorithm, run on a large enough fault-tolerant quantum computer, breaks RSA, finite-field Diffie-Hellman, and elliptic-curve cryptography including X25519 and ECDSA. Symmetric ciphers such as AES-256 and ChaCha20 are not the weak point, so the bulk-encryption part of a tunnel is not what needs replacing.

No machine capable of this exists today. Estimates of what it would take have dropped, though. In 2019, Craig Gidney and Martin Ekerå estimated that factoring RSA-2048 would need about 20 million noisy qubits. In May 2025, Gidney published a revised estimate of under one million noisy qubits and under a week of runtime. These are resource estimates for a machine nobody has built, but they are the reason planning horizons have shortened.

Store-now-decrypt-later (SNDL)

SNDL means recording encrypted traffic now and decrypting it once a capable quantum computer exists. Government migration guidance, including NIST’s transition draft, treats this as a reason to move key exchange first. I can’t point to a documented case of someone archiving developer-tunnel traffic specifically. The argument is about risk: if a captured session is protected only by a classical key exchange, it is exposed whenever a quantum computer arrives, regardless of when it was recorded.

This applies mainly to key exchange. Signatures and certificates are not an SNDL target, because forging a signature only helps an attacker who can do it while the connection is live. That is why key exchange has been migrated before authentication across the industry.

Whether this matters for your tunnel depends on what crosses it and how long it has to stay confidential. Webhook payloads containing live credentials, customer data copied into a test environment, and unreleased source are all examples that could still be sensitive a decade from now.

---

2. Standards: where things stand in October 2026

On August 13, 2024, NIST published its first three post-quantum standards:

Standard	Algorithm	Origin	Purpose
FIPS 203	ML-KEM	CRYSTALS-Kyber	Key encapsulation (key exchange)
FIPS 204	ML-DSA	CRYSTALS-Dilithium	Digital signatures
FIPS 205	SLH-DSA	SPHINCS+	Hash-based digital signatures

Two further items are in progress. FN-DSA, based on Falcon, is specified in FIPS 206, which is still a draft, and finalization is expected around late 2026 or early 2027. In March 2025 NIST also selected HQC, a code-based KEM, as a backup alongside ML-KEM.

ML-KEM’s security rests on the hardness of the Module Learning With Errors problem over structured lattices. It is the algorithm that TLS, SSH, and VPN deployments have adopted for key exchange.

The migration timeline

NIST’s draft report IR 8547 (published November 12, 2024) proposes deprecating quantum-vulnerable public-key algorithms with 112-bit security, such as RSA-2048 and P-256 ECC, after 2030, and disallowing them after 2035. It remains a proposal, but federal policy and procurement language have been built around those dates. The NSA’s CNSA 2.0 suite for national security systems sets its own, earlier milestones and names ML-KEM-1024 and ML-DSA-87 as the algorithms.

---

3. Why hybrid key exchange is the common approach

A hybrid key exchange runs a classical exchange (X25519) and a post-quantum one (ML-KEM-768) in the same handshake and derives the session key from both. An attacker has to break both to recover the key. That covers two failure modes: a flaw found in the newer post-quantum code or math, and a future quantum break of the classical curve.

Governments don’t agree on whether hybrid is necessary:

• Germany’s BSI and France’s ANSSI require or strongly favor hybrid combinations with classical algorithms.
• The NSA states that it does not require hybrid deployments for national security systems. It will accept hybrid for interoperability and aims for pure CNSA 2.0 algorithms by the stated dates.
• NIST has been drafting guidance on combining key-establishment schemes (SP 800-227) rather than mandating hybrid.

So hybrid is the dominant practice on the public internet, particularly in TLS, but it is not a universal mandate.

How it works in TLS 1.3

The hybrid group used almost everywhere is X25519MLKEM768. It is defined in an IETF Internet-Draft, draft-ietf-tls-ecdhe-mlkem, which at the time of writing is still a draft (revision 05, May 2026). The draft also defines SecP256r1MLKEM768 and SecP384r1MLKEM1024. In the exchange:

1. The client’s key share is the ML-KEM-768 encapsulation key followed by its ephemeral X25519 public key.
2. The server’s key share is the ML-KEM ciphertext followed by its ephemeral X25519 public key.
3. Both sides compute the ML-KEM shared secret and the X25519 shared secret, concatenate them, and feed the result into the normal TLS 1.3 key schedule as the (EC)DHE input.

Because the key schedule is unchanged, the rest of the handshake and the symmetric record encryption work as before.

Sizes

Key exchange	Client key share	Server key share
X25519	32 bytes	32 bytes
ML-KEM-768 (encapsulation key / ciphertext)	1,184 bytes	1,088 bytes
X25519MLKEM768 (hybrid)	1,216 bytes	1,120 bytes

Compared with plain X25519, the hybrid adds 2,272 bytes (about 2.2 KiB) across the two key shares.

---

4. What this means for tunneling tools

Post-quantum support varies a lot between tools, so check each one rather than assuming.

SSH reverse tunnels. OpenSSH 10.0, released April 9, 2025, made the hybrid mlkem768x25519-sha256 the default key agreement for the client. If you use ssh -R to expose a local port through a server running a recent OpenSSH, the key exchange is already post-quantum hybrid by default. Version 10.1 added a warning when a connection does not use a post-quantum key exchange.

Cloudflare Tunnel. Cloudflare introduced a post-quantum mode for cloudflared in October 2022, using the draft Kyber hybrids that preceded the final standard. When enabled, cloudflared would not fall back to a non-post-quantum connection. At launch, Cloudflare noted that the tunnel’s control connection and authentication were not yet post-quantum. Cloudflare has also reported that over 60% of client traffic on its network used post-quantum encryption by February 2026, up from under 3% at the start of 2024. For the exact current behavior of your tunnel version, check Cloudflare’s documentation.

WireGuard-based tools. Tailscale’s documentation states that its WireGuard implementation is not post-quantum secure. It also explains that WireGuard deliberately avoids protocol agility, so ML-KEM cannot simply be swapped in. If a tool is built on WireGuard, ask the vendor what their plan is.

Tools you build or run on Go. Go 1.24 (February 2025) enabled X25519MLKEM768 by default in crypto/tls when Config.CurvePreferences is nil. A Go-based tunnel client or edge built with Go 1.24 or later therefore negotiates the hybrid group without code changes. Kubernetes v1.33, built with Go 1.24, picked this up automatically as a side effect. You can turn it off with GODEBUG=tlsmlkem=0, which is mainly useful when a buggy middlebox or server mishandles the larger handshake.

Other providers. I could not find public documentation confirming post-quantum key exchange for several other popular tunneling services. If you rely on one, ask the vendor whether the public leg and the agent leg both negotiate a hybrid group, and what happens on fallback.

One architectural point to check

If a provider terminates TLS at its edge, the public leg and the agent leg are separate TLS sessions. Post-quantum protection on one does not protect the other, so you need both. Even with both legs protected, the provider’s edge sees plaintext. For genuinely sensitive data, end-to-end encryption inside the tunnel matters more than the choice of key exchange on either leg.

---

5. Configuring hybrid TLS in Go

For Go 1.24 and later, the default already prefers the hybrid group. If you want to state the preference explicitly, for documentation or to pin it, do this:

package main

import (
	"crypto/tls"
	"log"
	"net/http"
)

func newServer() *http.Server {
	cfg := &tls.Config{
		MinVersion: tls.VersionTLS13,
		// Prefer the post-quantum hybrid; keep plain X25519 so clients
		// that don't support ML-KEM can still connect.
		CurvePreferences: []tls.CurveID{
			tls.X25519MLKEM768,
			tls.X25519,
		},
	}
	return &http.Server{
		Addr:      ":443",
		TLSConfig: cfg,
	}
}

func main() {
	srv := newServer()
	log.Fatal(srv.ListenAndServeTLS("cert.pem", "key.pem"))
}

Two details to note:

• TLS 1.3 cipher suites are not configurable in Go’s crypto/tls, so there is no need to list CipherSuites for a TLS 1.3-only server. The key exchange group is what determines post-quantum protection.
• Keeping tls.X25519 as a fallback means older clients still connect, but it also means a downgrade to classical key exchange is possible. If you control both ends, as you do with your own tunnel client and edge, you can drop the fallback and make the hybrid mandatory. This is the approach Cloudflare took with its --post-quantum flag.

The hybrid group only applies to TLS 1.3. A client that negotiates TLS 1.2 gets a purely classical handshake, which is why MinVersion: tls.VersionTLS13 matters here.

---

6. Performance: what the measurements show

The cost of hybrid key exchange comes almost entirely from the extra bytes in the handshake, not from computation. The numbers below come from large-scale deployments, not from a tunnel-specific benchmark, so treat them as indicative.

• Handshake latency. Chrome engineers reported on an IETF mailing list that adding Kyber to the TLS handshake raised handshake latency by about 4% on desktop and about 9% on Android at the median, and considerably more at the 95th percentile. Cloudflare’s measurements found that each additional 1 KB in the server response raised median HTTPS handshake latency by about 1.5%. These are percentage increases in the handshake only, not in total page-load or request time.
• Middlebox and server compatibility. The larger ClientHello can trigger bugs in poorly written servers and middleboxes. Cloudflare found that around 0.34% of the origins it scanned failed to complete a handshake when sent a post-quantum key share first. Go documents tlsmlkem=0 as the workaround for buggy servers that don’t handle large records.
• Retry cost. If a client guesses wrong about which group a server supports, TLS 1.3 needs an extra round trip (a HelloRetryRequest). Cloudflare reported cutting such retries on scanned origins from roughly 52% to 3.7% by measuring each origin’s preference, which removed more than 150 ms from p90 handshake latency.
• After the handshake. Bulk data is protected by the same symmetric cipher as before (AES-GCM or ChaCha20-Poly1305), so per-byte throughput does not change. AWS’s analysis of hybrid TLS makes a related point: the extra cost is paid once per connection and amortized over the session, and connection pooling reduces its impact further.

For tunnels, this is favorable. The agent leg is typically one long-lived multiplexed connection, so you pay the handshake cost once. For the public leg, the cost lands on each new connection, but webhook senders and browsers that reuse connections pay it less often. I don’t have a measurement showing a specific millisecond figure for tunnel previews, and you should be wary of any article that quotes one without describing the test setup. If this matters to you, measure your own tunnel with the hybrid group on and off.

---

7. Practical steps for your stack

1. Inventory your tunnels. List every tool you use to expose local services (SSH, a commercial provider, an agent you run yourself) and check each one’s documentation for ML-KEM or X25519MLKEM768 support on both legs.
2. Prefer tools that default to the hybrid. OpenSSH 10.0 or later and Go 1.24 or later already do. Update clients and servers rather than configuring this by hand.
3. Verify, don’t assume. Inspect a real handshake from the client side with OpenSSL or a packet capture and confirm that the negotiated group is a hybrid. Treat a silent fallback to X25519 as a finding.
4. Require TLS 1.3 where you control both ends. TLS 1.2 handshakes are always classical.
5. Don’t rely on transport encryption alone for secrets. Keep production credentials out of local environments, use short-lived scoped tokens, and avoid sending real customer data through a tunnel. This limits the damage from any recorded traffic, whatever algorithm protected it.
6. Plan for authentication separately. Post-quantum certificates and signatures are a harder migration than key exchange and are not yet widely deployed on the public web. Short-lived certificates are good hygiene, but they do not address store-now-decrypt-later, which targets key exchange.
7. Stay crypto-agile. FN-DSA and HQC are still moving through standardization, and the TLS hybrid is still an Internet-Draft. Pick tools that can change algorithms through a configuration or update rather than a rebuild.

---

Conclusion

The practical picture for local tunnels is better than the headlines suggest. Post-quantum key exchange is standardized, shipping by default in widely used software such as OpenSSH 10 and Go 1.24, and measured at modest handshake cost. The remaining work is mostly verification and tool selection. Check whether both legs of your tunnel negotiate a hybrid group, keep secrets out of tunneled traffic, and treat post-quantum authentication as the next step rather than the first.

---

References

• NIST FIPS 203, 204, 205 (finalized August 13, 2024) and status of FIPS 206 and HQC: Encryption Consulting – Decoding NIST PQC Standards; NIST PQC overview slides
• NIST IR 8547 timeline (2030 deprecation, 2035 disallowance, proposed): Encryption Consulting – NIST IR 8547 Explained
• TLS hybrid key exchange draft: draft-ietf-tls-ecdhe-mlkem
• ML-KEM-768 sizes: facil.io ML-KEM-768 reference
• Hybrid policy positions (NSA, BSI, ANSSI): PostQuantum.com – Global PQC Requirements; PQShield – CNSA 2.0 update
• Go 1.24 default hybrid: Go GODEBUG documentation; Kubernetes blog – PQC in Kubernetes
• OpenSSH 10.0 release notes: openssh.com
• Cloudflare Tunnel post-quantum mode: Introducing post-quantum Cloudflare Tunnel
• Cloudflare adoption data: Bringing more transparency to post-quantum usage
• Tailscale and WireGuard: Tailscale post-quantum cryptography documentation
• Handshake latency data: IETF TLS list – Chrome and Cloudflare measurements; AWS Security Blog – Performance of hybrid post-quantum TLS; InfoQ – Cloudflare origin TLS preferences
• RSA-2048 resource estimate: Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits”