Post-Quanten-TLS: Was der hybride Schlüsselaustausch schützt

Warum der Schlüsselaustausch zuerst kommt

Einen Quantenrechner, der elliptische Kurven bricht, gibt es heute nicht. Eine Gefahr ist er trotzdem schon: Wer verschlüsselten Verkehr jetzt mitschneidet und speichert, kann ihn entschlüsseln, sobald es ihn gibt. Das BSI nennt dieses Szenario „Store Now, Decrypt Later“ und sieht darin schon heute eine Bedrohung für Daten mit längerfristigem Schutzbedarf. Dazu gehören etwa Gesundheitsdaten oder Verträge.

Die Gefahr betrifft den Schlüsselaustausch, nicht die Signaturen. Aus dem Austausch entsteht der Schlüssel, mit dem die Sitzung verschlüsselt wird; wer ihn später aus dem Mitschnitt berechnen kann, liest alles nach. Eine Signatur beweist dagegen nur im Moment des Verbindungsaufbaus, dass der Server echt ist. Wer sie in zehn Jahren fälschen kann, gewinnt an einer Verbindung von heute nichts mehr. Deshalb stellen Browser und Server zuerst den Schlüsselaustausch um, und deshalb auch wir.

Was hybrid heißt

X25519MLKEM768 verbindet zwei Verfahren in einem Schritt. Der Client schickt in seiner ersten Nachricht einen öffentlichen X25519-Schlüssel und einen öffentlichen ML-KEM-768-Schlüssel mit, der Server antwortet mit seinem X25519-Anteil und einem ML-KEM-Chiffrat. Beide Seiten erhalten so zwei gemeinsame Geheimnisse, die zusammen in die Schlüsselableitung von TLS 1.3 eingehen. Wer die Sitzung lesen will, muss beide Verfahren brechen: X25519 gilt gegen heutige Rechner als sicher, ML-KEM ist gegen Quantenrechner entworfen.

Warum nicht ML-KEM allein? Weil das Verfahren jung ist. Das NIST hat es im August 2024 als FIPS 203 standardisiert; X25519 hat rund zwei Jahrzehnte Analyse hinter sich. Zeigt sich in ML-KEM eine Schwäche, schützt X25519 weiter wie bisher. Das BSI empfiehlt Post-Quanten-Verfahren aus diesem Grund nur in einer solchen Kombination.

Die IETF hat die Kombination inzwischen beschrieben und standardisiert: RFC 9954 erklärt seit Juli 2026, wie TLS 1.3 zwei Verfahren verbindet, der Standard RFC 10024 legt seit August 2026 die Gruppen X25519MLKEM768 (Codepunkt 0x11EC), SecP256r1MLKEM768 und SecP384r1MLKEM1024 fest. Der Preis sind Bytes: Ein öffentlicher ML-KEM-768-Schlüssel ist 1.184 Byte groß, ein Chiffrat 1.088 Byte. Die erste Nachricht des Clients überschreitet damit oft die Größe eines einzelnen Pakets, und vereinzelt kommen veraltete Netzwerkgeräte damit nicht zurecht.

Was bei obhut heute gilt

HTTPS-Verbindungen kommen bei obhut an zwei Stellen an: am Edge, der die Anwendungen und Websites unserer Kunden ausliefert, und am Gateway vor Website, Dashboard, Anmeldung und API. Beide haben wir von außen geprüft.

Das ist keine zufällige Voreinstellung, sondern festgehalten. Der Edge überlässt den Austausch der Standardbibliothek von Go, die seit Version 1.24 X25519MLKEM768 wählt, wenn der Client es anbietet. Ein automatischer Test baut Verbindungen mit den Gruppen eines Browsers und mit rein klassischen Gruppen auf; er schlägt fehl, sobald eine Konfiguration den hybriden Austausch abwählt oder ein klassischer Client nicht mehr verbinden kann. Für das Gateway startet eine zweite Prüfung die echte Konfiguration mit TLS und verlangt dasselbe für jeden Hostnamen. Beide laufen bei jeder Änderung an Edge oder Gateway. Sie decken X25519MLKEM768 ab; die beiden Varianten mit NIST-Kurven sind am Edge die Voreinstellung von Go ab Version 1.26.

Hinter dem Edge geht es weiter, wo die Gegenseite mitspielt. Zu einem HTTPS-Ursprung baut der Edge eine eigene TLS-Verbindung auf und bietet dabei ebenfalls X25519MLKEM768 an; ob der hybride Austausch zustande kommt, entscheidet der Server des Ursprungs. Server mit OpenSSL ab Version 3.5, Go ab 1.24 oder Caddy ab 2.10 wählen ihn in der Voreinstellung, sofern ihre Konfiguration die Gruppen nicht einschränkt. Der HTTP-Tunnel zwischen Connector und Edge ist eine SSH-Verbindung; beide Seiten verwenden die SSH-Bibliothek von Go, die seit 2025 den hybriden Austausch mlkem768x25519-sha256 an erster Stelle anbietet.

Was noch klassisch ist

Die Zertifikate. obhut bestellt sie bei Let's Encrypt, mit Schlüsseln auf der Kurve P-256, signiert mit klassischen Verfahren. Ein ausreichend großer Quantenrechner könnte solche Signaturen fälschen und sich als Server ausgeben, aber erst ab dem Tag, an dem es ihn gibt, und nur bei Verbindungen, die er in diesem Moment angreift. Vergangene Mitschnitte öffnet eine gefälschte Signatur nicht.

Für die Zertifikate gibt es einen Plan, aber noch kein fertiges Format. Google hat im Februar 2026 angekündigt, vorerst keine klassischen X.509-Zertifikate mit Post-Quanten-Signaturen in den Root Store von Chrome aufzunehmen. Chrome setzt stattdessen auf Merkle Tree Certificates, die eine Arbeitsgruppe der IETF entwickelt: kompakte Nachweise statt langer Ketten großer Signaturen. Ab dem ersten Quartal 2027 sollen Betreiber von Certificate-Transparency-Logs öffentliche Merkle Tree Certificates aufbauen; früh in dieser Phase will Chrome auch die Anforderungen an einen eigenen, quantenresistenten Root Store festlegen, in den ab dem dritten Quartal 2027 weitere Zertifizierungsstellen aufgenommen werden sollen. Let's Encrypt plant solche Zertifikate für Ende 2026 in seiner Testumgebung und für 2027 im Produktivbetrieb. Sobald eine Zertifizierungsstelle sie über ACME ausstellt, wollen wir sie neben den bisherigen bestellen.

Und nicht jeder Client bietet den hybriden Austausch an. Chrome bietet X25519MLKEM768 seit Version 131 (November 2024) an, Firefox am Desktop seit Version 132 (Oktober 2024), Apple-Geräte ab iOS 26, iPadOS 26 und macOS Tahoe 26. Ältere Browser, viele Skripte und Bibliotheken erhalten weiter einen klassischen Austausch; für sie gilt der Schutz vor späterer Entschlüsselung nicht.

Was BSI und EU empfehlen

Das BSI empfiehlt in seiner Technischen Richtlinie TR-02102-1 (Stand Januar 2026) Post-Quanten-Verfahren für den Schlüsselaustausch nur in Kombination mit klassischen und nennt ML-KEM-768 und ML-KEM-1024 als geeignet. Rein klassische Verfahren empfiehlt es nur noch bis Ende 2031, bei sehr hohem Schutzbedarf bis Ende 2030.

Für TLS ist die Richtlinie strenger, als es Browser heute sind. TR-02102-2 führt X25519 nicht unter den empfohlenen Gruppen; das BSI will stattdessen SecP256r1MLKEM768 und SecP384r1MLKEM1024 empfehlen, sobald deren Standard erschienen ist. Das ist mit RFC 10024 im August 2026 geschehen. Browser bieten heute X25519MLKEM768 an. Der Edge von obhut beherrscht alle drei Gruppen. Das Gateway vor Website und Dashboard beherrscht bisher nur X25519MLKEM768: Ein Client, der als hybride Gruppen ausschließlich die NIST-Varianten anbietet, erhält dort einen klassischen Austausch, und ohne klassische Gruppe im Angebot keine Verbindung.

Auf europäischer Ebene hat die NIS-Kooperationsgruppe im Juni 2025 einen gemeinsamen Fahrplan veröffentlicht: erste Schritte und nationale Pläne bis Ende 2026, Anwendungen mit hohem Risiko bis Ende 2030 umgestellt, solche mit mittlerem Risiko bis Ende 2035. Das ist eine abgestimmte Empfehlung der Mitgliedstaaten, kein Gesetz. Das NIST schlägt in einem Entwurf vor, klassische Verfahren wie RSA und elliptische Kurven nach 2035 nicht mehr zuzulassen.

Selbst prüfen

Mit OpenSSL ab Version 3.5 lässt sich die Gruppe erzwingen:

openssl s_client \
  -connect obhut.io:443 \
  -groups X25519MLKEM768 \
  -brief </dev/null

Kommt die Verbindung zustande, nennt die Ausgabe die ausgehandelte Gruppe, mit OpenSSL 3.6 als Negotiated TLS1.3 group: X25519MLKEM768. Beherrscht der Server die Gruppe nicht, bricht der Aufbau mit einem Fehler ab. Mit dem Hostnamen einer Anwendung hinter obhut prüfen Sie den Edge und dort mit -groups SecP256r1MLKEM768 auch die Variante, die das BSI empfehlen will; das Gateway vor obhut.io beherrscht sie noch nicht. Für Apple-Geräte beschreibt Apple einen eigenen Test mit nscurl --tls-diagnostics unter macOS Tahoe 26.

Häufige Fragen

Ist mein Verkehr damit quantensicher?

Seine Vertraulichkeit gegen spätere Entschlüsselung ja, sofern der Client den hybriden Austausch anbietet und ML-KEM hält. Hinter dem Edge gilt das nur, wenn auch Ihr Ursprung den hybriden Austausch beherrscht. Die Echtheit des Servers beruht weiter auf klassischen Signaturen; angreifbar ist sie erst, wenn ein passender Quantenrechner tatsächlich existiert.

Muss ich dafür etwas einstellen?

Nein. Edge und Gateway handeln den hybriden Austausch selbstständig aus, für jeden Hostnamen. Für den Abschnitt vom Edge zu Ihrem HTTPS-Ursprung entscheidet Ihr Server; aktuelle Versionen von OpenSSL, Go und Caddy wählen ihn in der Voreinstellung.

Kann der größere Handshake Probleme machen?

Selten. Die erste Nachricht des Clients wird um gut 1,2 Kilobyte größer. Einzelne veraltete Firewalls und Proxys kommen mit solchen Nachrichten nicht zurecht; betroffen ist dann der Netzweg des Clients, nicht der Server.

Gilt das auch für Dashboard und Anmeldung?

Ja. Website, Dashboard, Anmeldung und API laufen hinter einem Gateway, das X25519MLKEM768 ebenso aushandelt wie der Edge.

Wann werden die Zertifikate umgestellt?

Wenn es ein Format gibt, dem Browser vertrauen. Nach heutigem Plan sind das Merkle Tree Certificates, öffentlich ab 2027. Bis dahin bleibt es bei ECDSA, und der hybride Austausch schützt die Vertraulichkeit schon jetzt.