Quantensichere lokale Tunnels: Vorbereitung Ihres Entwicklungstacks auf Post-Quantum-Kryptografie

Quantencomputing ist ein Thema für Sicherheitsteams und Normungsorganisationen. NIST hat einen Termin für die Abschaffung der heutigen Public-Key-Algorithmen vorgeschlagen, und große CDNs sowie Betriebssysteme verhandeln bereits standardmäßig über post-quantum Schlüsselaustausch. Ein Teil des Stacks erhält bei dieser Migration wenig Aufmerksamkeit: der lokale Entwicklungstunnel.

Entwickler verwenden Tunnel, um localhost für Webhook-Anbieter, mobile Testgeräte und Kunden, die einen Staging-Build prüfen, zugänglich zu machen. Ein Tunnel ist eine TLS-geschützte Verbindung, die die gleichen kryptografischen Risiken wie jede andere TLS-Verbindung birgt. Er trägt auch oft sensible Daten wie API-Schlüssel, Sitzungstokens und Payloads, die aus echten Systemen kopiert wurden.

Dieser Leitfaden erklärt, was ein Quantencomputer in einem Tunnel brechen könnte und was nicht. Er behandelt auch, was die Standards heute sagen und wie hybrider Schlüsselaustausch in TLS 1.3 funktioniert. Außerdem wird untersucht, welche Tunneling-Tools bereits post-quantum Schlüsselaustausch unterstützen und welche Leistungsaufnahme dabei gemessen wurde.

---

1. Was in einem Tunnel tatsächlich gefährdet ist

Die Anatomie einer Tunnelverbindung

Ein Tunnel besteht aus zwei Teilen:

1. Öffentlicher Teil: Ein Browser, eine mobile App oder ein Webhook-Sender verbindet sich über TLS mit dem öffentlichen Rand des Tunnel-Anbieters.
2. Agenten-Teil: Ein Client-Daemon auf Ihrem Laptop hält eine langanhaltende ausgehende Verbindung zum selben Rand, und Anfragen werden darin multiplexed.

Jeder Teil ist durch seinen eigenen kryptografischen Handshake geschützt. In TLS 1.3 stammen die Sitzungs-Keys aus einem ephemeren (EC)DHE-Schlüsselaustausch, meist X25519. Das Serverzertifikat wird mit einer Signatur wie RSA oder ECDSA verifiziert. Ein Tunnel, der nur einen dieser Teile schützt, lässt den anderen klassisch. Beide Beine können das schwächere sein.

Warum Shor’s Algorithmus hier relevant ist

Shor’s Algorithmus, ausgeführt auf einem ausreichend großen fehler-toleranten Quantencomputer, bricht RSA, finite-Field Diffie-Hellman und elliptische Kurven-Kryptografie inklusive X25519 und ECDSA. Symmetrische Verschlüsselungen wie AES-256 und ChaCha20 sind nicht schwach, daher ist der Bulk-Verschlüsselungsteil eines Tunnels nicht das Problem.

Ein solches Gerät existiert heute nicht. Schätzungen, was es bräuchte, sind jedoch gesunken. 2019 schätzten Craig Gidney und Martin Ekerå, dass das Faktorisieren von RSA-2048 etwa 20 Millionen verrauschte Qubits erfordern würde. Im Mai 2025 veröffentlichte Gidney eine aktualisierte Schätzung unter einer Million verrauschte Qubits und unter einer Woche Laufzeit. Diese Ressourcen-Schätzungen beziehen sich auf eine Maschine, die niemand gebaut hat, sind aber Grund für die verkürzten Planungszeiträume.

Store-now-decrypt-later (SNDL)

SNDL bedeutet, verschlüsselten Traffic jetzt aufzuzeichnen und ihn zu entschlüsseln, sobald ein leistungsfähiger Quantencomputer existiert. Die Migrationsrichtlinien der Regierung, inklusive des NIST-Entwurfs, betrachten dies als Grund, den Schlüsselaustausch zuerst anzugehen. Es gibt keine dokumentierten Fälle, in denen Entwickler-Tunnel-Traffic speziell archiviert wurde. Das Argument ist das Risiko: Wenn eine Sitzung nur durch einen klassischen Schlüsselaustausch geschützt ist, ist sie offen, sobald ein Quantencomputer verfügbar ist, egal wann sie aufgezeichnet wurde.

Dies betrifft hauptsächlich Schlüsselaustausch. Signaturen und Zertifikate sind kein SNDL-Ziel, weil das Fälschen einer Signatur nur einem Angreifer hilft, der es während der Verbindung schafft. Deshalb wurde der Schlüsselaustausch vor der Authentifizierung in der Industrie migriert.

Ob das für Ihren Tunnel relevant ist, hängt davon ab, was ihn durchquert und wie lange es vertraulich bleiben muss. Payloads von Webhooks mit Live-Zugangsdaten, Kundendaten, die in eine Testumgebung kopiert wurden, und unveröffentlichter Quellcode sind alles Beispiele, die auch in zehn Jahren noch sensibel sein könnten.

---

2. Stand der Standards im Oktober 2026

Am 13. August 2024 veröffentlichte NIST die ersten drei post-quantum Standards:

Standard	Algorithmus	Herkunft	Zweck
FIPS 203	ML-KEM	CRYSTALS-Kyber	Schlüsselaustausch (Key Encapsulation)
FIPS 204	ML-DSA	CRYSTALS-Dilithium	Digitale Signaturen
FIPS 205	SLH-DSA	SPHINCS+	Hash-basierte digitale Signaturen

Zwei weitere sind in Bearbeitung. FN-DSA, basierend auf Falcon, ist in FIPS 206 spezifiziert, das noch ein Entwurf ist, und die Finalisierung wird voraussichtlich Ende 2026 oder Anfang 2027 erfolgen. Im März 2025 wählte NIST außerdem HQC, ein code-basiertes KEM, als Backup neben ML-KEM.

Die Sicherheit von ML-KEM basiert auf der Schwierigkeit des Module Learning With Errors Problems über strukturierte Gitter. Es ist der Algorithmus, den TLS, SSH und VPN-Implementierungen für den Schlüsselaustausch übernommen haben.

Migrationszeitplan

Der Entwurfsbericht IR 8547 von NIST (veröffentlicht am 12. November 2024) schlägt vor, public-key Algorithmen mit 112-Bit-Sicherheit, wie RSA-2048 und P-256 ECC, nach 2030 zu deprezieren und nach 2035 zu verbieten. Es ist noch ein Vorschlag, aber die Bundespolitik und Beschaffungssprache sind bereits auf diese Termine ausgerichtet. Die NSA’s CNSA 2.0 Suite für nationale Sicherheitssysteme setzt ihre eigenen, früheren Meilensteine und nennt ML-KEM-1024 und ML-DSA-87 als die Algorithmen.

---

3. Warum hybrider Schlüsselaustausch die gängige Methode ist

Ein hybrider Schlüsselaustausch kombiniert einen klassischen Austausch (X25519) mit einem post-quantum Austausch (ML-KEM-768) im selben Handshake und leitet den Sitzungsschlüssel aus beiden ab. Ein Angreifer muss beide brechen, um den Schlüssel zu rekonstruieren. Damit werden zwei Ausfallmodi abgedeckt: ein Fehler im neueren post-quantum Code oder Mathematik, und ein zukünftiger Quantenbruch der klassischen Kurve.

Regierungen sind sich uneins, ob Hybrid notwendig ist:

• Deutschland’s BSI und Frankreich’s ANSSI fordern oder bevorzugen hybride Kombinationen mit klassischen Algorithmen.
• Die NSA erklärt, dass sie keine hybriden Deployments für nationale Sicherheitssysteme verlangt. Sie akzeptiert Hybrid für Interoperabilität und strebt reine CNSA 2.0 Algorithmen bis zu den genannten Terminen an.
• NIST arbeitet an Leitlinien zur Kombination von Schlüsselaustausch-Methoden (SP 800-227), ohne Hybrid zu vorschreiben.

Daher ist Hybrid die vorherrschende Praxis im öffentlichen Internet, insbesondere in TLS, aber es ist kein universelles Mandat.

So funktioniert es in TLS 1.3

Die meistverwendete Hybrid-Gruppe ist X25519MLKEM768. Sie ist in einem IETF-Entwurf draft-ietf-tls-ecdhe-mlkem definiert, der zum Zeitpunkt des Schreibens noch ein Entwurf ist (Revision 05, Mai 2026). Der Entwurf definiert auch SecP256r1MLKEM768 und SecP384r1MLKEM1024. Im Austausch:

1. Der Key-Share des Clients ist der ML-KEM-768 Encapsulation-Key gefolgt von seinem ephemeren X25519 öffentlichen Schlüssel.
2. Der Key-Share des Servers ist die ML-KEM Ciphertext gefolgt von seinem ephemeren X25519 öffentlichen Schlüssel.
3. Beide Seiten berechnen den gemeinsamen ML-KEM-Schlüssel und den X25519-Schlüssel, diese concatenieren und in den normalen TLS 1.3 Schlüssel-Algorithmus einspeisen als (EC)DHE-Eingang.

Da der Schlüssel-Algorithmus unverändert bleibt, funktioniert der Rest des Handshakes und die symmetrische Verschlüsselung wie zuvor.

Größen

Schlüsselaustausch	Client-Schlüsselanteil	Server-Schlüsselanteil
X25519	32 Bytes	32 Bytes
ML-KEM-768 (Encapsulation)	1.184 Bytes	1.088 Bytes
X25519MLKEM768 (hybrid)	1.216 Bytes	1.120 Bytes

Im Vergleich zu einfachem X25519 erhöht der Hybrid-Ansatz die Datenmenge um 2.272 Bytes (etwa 2,2 KiB) bei den beiden Schlüsselanteilen.

---

4. Was das für Tunneling-Tools bedeutet

Post-quantum Unterstützung variiert stark zwischen Tools. Prüfen Sie jedes einzelne, anstatt Annahmen zu treffen.

SSH Reverse Tunnels. OpenSSH 10.0, veröffentlicht am 9. April 2025, setzt den hybriden mlkem768x25519-sha256 als Standard für den Schlüsselaustausch. Wenn Sie ssh -R verwenden, um einen lokalen Port durch einen Server mit einer aktuellen OpenSSH-Version freizugeben, ist der Schlüsselaustausch bereits standardmäßig post-quantum hybrid. Version 10.1 warnt, wenn kein post-quantum Schlüsselaustausch genutzt wird.

Cloudflare Tunnel. Cloudflare führte im Oktober 2022 einen post-quantum Modus für cloudflared ein, der die Entwürfe für Kyber-Hybride nutzt, noch vor der finalen Norm. Bei Aktivierung fällt cloudflared nicht auf eine nicht-post-quantum Verbindung zurück. Zum Start wurde erwähnt, dass die Steuer- und Authentifizierungsverbindung noch nicht post-quantum ist. Cloudflare berichtete, dass bis Februar 2026 über 60 % des Client-Traffics auf ihrem Netzwerk post-quantum Verschlüsselung nutzte, gegenüber weniger als 3 % Anfang 2024. Für das aktuelle Verhalten Ihres Tunnels prüfen Sie bitte die Dokumentation.

WireGuard-basierte Tools. Tailscale gibt an, dass seine WireGuard-Implementierung nicht post-quantum sicher ist. Es wird auch erklärt, dass WireGuard Protocol-Agilität bewusst vermeidet, sodass ML-KEM nicht einfach ausgetauscht werden kann. Wenn ein Tool auf WireGuard basiert, fragen Sie den Anbieter nach seinen Plänen.

Tools, die Sie in Go bauen oder betreiben. Go 1.24 (Februar 2025) aktiviert standardmäßig X25519MLKEM768 in crypto/tls, wenn Config.CurvePreferences nil ist. Ein in Go 1.24 oder später gebauter Tunnel-Client oder -Edge verhandelt somit automatisch die Hybrid-Gruppe. Kubernetes v1.33, gebaut mit Go 1.24, nutzt dies ebenfalls automatisch. Sie können es mit GODEBUG=tlsmlkem=0 deaktivieren, was vor allem bei fehlerhaften Mittelsystemen oder Servern nützlich ist.

Andere Anbieter. Für mehrere andere beliebte Tunneling-Dienste konnte ich keine öffentliche Dokumentation zum post-quantum Schlüsselaustausch finden. Fragen Sie den Anbieter, ob beide Beine eine Hybrid-Gruppe verhandeln und was bei Fallback passiert.

Ein architektonischer Punkt

Wenn ein Anbieter TLS an seinem Rand terminiert, sind das öffentliche und das Agenten-Bein separate TLS-Sitzungen. Post-quantum Schutz auf einem Bein schützt das andere nicht, beide müssen geschützt sein. Auch bei beiden Beinen ist der Rand des Anbieters nur im Klartext sichtbar. Für wirklich sensible Daten ist End-to-End-Verschlüsselung im Tunnel wichtiger als die Wahl des Schlüsselaustausch-Algorithmus.

---

5. Konfiguration hybrider TLS in Go

Ab Go 1.24 ist die Standardkonfiguration bereits auf die Hybrid-Gruppe ausgerichtet. Wenn Sie die Präferenz explizit festlegen möchten, z.B. für Dokumentation oder Fixierung, verwenden Sie:

package main

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

func newServer() *http.Server {
	cfg := &tls.Config{
		MinVersion: tls.VersionTLS13,
		// Bevorzugen Sie die post-quantum Hybrid; lassen Sie X25519 als Fallback, damit Clients ohne ML-KEM noch verbinden können.
		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"))
}

Zwei Hinweise:

• TLS 1.3 Cipher Suites sind in Go’s crypto/tls nicht konfigurierbar, es ist also nicht notwendig, CipherSuites aufzulisten. Die Schlüsselaustauschgruppe bestimmt die Post-Quantum-Sicherheit.
• Das Beibehalten von tls.X25519 als Fallback ermöglicht ältere Clients die Verbindung, erhöht aber auch die Gefahr eines Downgrades auf klassischen Schlüsselaustausch. Wenn beide Enden kontrolliert werden, kann man den Fallback entfernen und Hybrid verpflichtend machen. Das hat Cloudflare mit seinem --post-quantum-Flag umgesetzt.

Der Hybrid-Group gilt nur für TLS 1.3. Ein Client, der TLS 1.2 aushandelt, erhält einen rein klassischen Handshake, weshalb MinVersion: tls.VersionTLS13 hier wichtig ist.

---

6. Leistung: Was die Messungen zeigen

Die Kosten für den hybriden Schlüsselaustausch liegen fast ausschließlich in den zusätzlichen Bytes im Handshake, nicht in der Berechnung. Die Zahlen stammen aus groß angelegten Deployments, nicht aus einem Tunnel-spezifischen Benchmark, daher nur als Richtwerte.

• Handshake-Latenz. Chrome-Entwickler berichteten in einer IETF-Mail, dass das Hinzufügen von Kyber zum TLS-Handshake die Latenz um ca. 4 % auf Desktop und ca. 9 % auf Android im Median erhöhte, deutlich mehr bei den 95. Perzentilen. Cloudflare fand, dass jede zusätzliche 1 KB in der Server-Antwort die mediane HTTPS-Handshake-Latenz um ca. 1,5 % erhöhte. Diese Prozentsätze beziehen sich nur auf den Handshake, nicht auf die gesamte Seitenlade- oder Request-Zeit.
• Kompatibilität mit Mittelsystemen und Servern. Das größere ClientHello kann Bugs in schlecht geschriebenen Servern und Mittelsystemen auslösen. Cloudflare fand, dass etwa 0,34 % der untersuchten Ursprünge den Handshake bei einem post-quantum Schlüsselaustausch nicht abschließen konnten. Go dokumentiert tlsmlkem=0 als Workaround für fehlerhafte Server.
• Wiederholungsaufwand. Wenn ein Client falsch schätzt, welche Gruppe ein Server unterstützt, braucht TLS 1.3 eine zusätzliche Runde (HelloRetryRequest). Cloudflare reduzierte solche Wiederholungen bei untersuchten Ursprüngen von etwa 52 % auf 3,7 %, was mehr als 150 ms im p90-Handshakelast spart.
• Nach dem Handshake. Die Datenübertragung erfolgt mit derselben symmetrischen Verschlüsselung wie zuvor (AES-GCM oder ChaCha20-Poly1305), die Durchsatzrate ändert sich also nicht. AWS stellte fest, dass die Mehrkosten einmal pro Verbindung anfallen und über die Sitzung verteilt werden. Verbindungspooling verringert die Auswirkungen weiter.

Für Tunnel ist das günstig: Das Agenten-Bein ist meist eine langlebige, multiplexte Verbindung, daher fallen die Handshake-Kosten nur einmal an. Für das öffentliche Bein entstehen die Kosten bei jeder neuen Verbindung, aber Webhook-Sender und Browser, die Verbindungen wiederverwenden, bezahlen es weniger oft. Es gibt keine spezifische Messung in Millisekunden für Tunnel-Vorschauen, und man sollte vorsichtig sein bei Artikeln, die eine Zahl ohne Testsetup nennen. Wenn es für Sie relevant ist, messen Sie Ihren eigenen Tunnel mit aktiviertem und deaktiviertem Hybrid.

---

7. Praktische Schritte für Ihren Stack

1. Inventarisieren Sie Ihre Tunnel. Listen Sie alle Tools auf, mit denen Sie lokale Dienste exponieren (SSH, ein kommerzieller Anbieter, ein eigener Agent), und prüfen Sie die Dokumentation auf Unterstützung für ML-KEM oder X25519MLKEM768 auf beiden Beinen.
2. Bevorzugen Sie Tools, die standardmäßig auf Hybrid setzen. OpenSSH 10.0 oder später und Go 1.24 oder später tun das bereits. Aktualisieren Sie Clients und Server, statt dies manuell zu konfigurieren.
3. Verifizieren Sie, statt zu vermuten. Überprüfen Sie einen echten Handshake auf Client-Seite mit OpenSSL oder einem Paket-Sniffer und bestätigen Sie, dass die verhandelte Gruppe hybrid ist. Ein stilles Downgrade auf X25519 gilt als Feststellung.
4. Verlangen Sie TLS 1.3, wenn beide Enden kontrollieren. TLS 1.2-Handshakes sind immer klassisch.
5. Verlassen Sie sich nicht nur auf Transportverschlüsselung für Secrets. Halten Sie Produktionszugänge außerhalb der lokalen Umgebung, verwenden Sie kurzlebige Tokens und vermeiden Sie, echte Kundendaten durch einen Tunnel zu schicken. Das begrenzt den Schaden bei aufgezeichnetem Traffic, egal welches Algorithmus verwendet wurde.
6. Planen Sie Authentifizierung separat. Post-quantum Zertifikate und Signaturen sind eine schwierigere Migration und noch nicht breit im Web implementiert. Kurzlebige Zertifikate sind gute Hygiene, adressieren aber nicht Store-Now-Decrypt-Later, das auf Schlüsselaustausch abzielt.
7. Bleiben Sie kryptografisch agil. FN-DSA und HQC sind noch in Standardisierung, und der TLS-Hybrid ist noch ein Internet-Draft. Wählen Sie Tools, die Algorithmen per Konfiguration oder Update ändern können, ohne neu bauen zu müssen.

---

Fazit

Die praktische Lage für lokale Tunnel ist besser, als die Überschriften vermuten lassen. Post-quantum Schlüsselaustausch ist standardisiert, ist in weit verbreiteter Software wie OpenSSH 10 und Go 1.24 standardmäßig enthalten und verursacht nur moderate Handshake-Kosten. Die verbleibende Arbeit besteht vor allem in der Verifikation und Tool-Auswahl. Prüfen Sie, ob beide Beine Ihres Tunnels eine Hybrid-Gruppe verhandeln, halten Sie Secrets außerhalb des Tunnels, und betrachten Sie post-quantum Authentifizierung als nächsten Schritt, nicht als ersten.

---

Quellen

• NIST FIPS 203, 204, 205 (finalisiert am 13. August 2024) und Stand von FIPS 206 und HQC: Encryption Consulting – Decoding NIST PQC Standards; NIST PQC overview slides
• NIST IR 8547 Zeitplan (2030 Abschaffung, 2035 Verbot, Vorschlag): Encryption Consulting – NIST IR 8547 Explained
• TLS Hybrid-Schlüsselaustausch-Entwurf: draft-ietf-tls-ecdhe-mlkem
• ML-KEM-768 Größen: facil.io ML-KEM-768 Referenz
• Hybrid-Politik (NSA, BSI, ANSSI): PostQuantum.com – Globale PQC-Anforderungen; PQShield – CNSA 2.0 Update
• Go 1.24 Standard-Hybrid: Go GODEBUG Dokumentation; Kubernetes Blog – PQC in Kubernetes
• OpenSSH 10.0 Release Notes: openssh.com
• Cloudflare Tunnel Post-Quantum Mode: Introducing post-quantum Cloudflare Tunnel
• Cloudflare-Adoptionsdaten: Mehr Transparenz bei post-quantum Nutzung
• Tailscale und WireGuard: Tailscale Post-Quantum-Kryptografie
• Handshake-Latenz: IETF TLS-Liste – Chrome- und Cloudflare-Messungen; AWS Security Blog – Leistung von hybridem post-quantum TLS; InfoQ – Cloudflare Origin TLS Präferenzen
• RSA-2048 Ressourcen-Schätzung: Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits”