Zum Inhalt springen
Cybersicherheit · Cloud & DevOps · TLS 1.3

Post-Quanten-TLS:
Hybrides ML-KEM ohne Ausfall einführen

Veröffentlicht: 12. September 2026·Zaid Aljbour, Geschäftsführer·12 Min. Lesezeit

Post-Quanten-TLS schützt den Schlüsselaustausch einer TLS-1.3-Verbindung gegen künftige Quantenangriffe. Für eine risikoarme Einführung ist derzeit ein hybrides Verfahren sinnvoll: X25519MLKEM768 kombiniert den klassischen X25519-Austausch mit dem von NIST standardisierten ML-KEM.

Der schwierige Teil ist nicht der Name des Algorithmus, sondern der vollständige Verbindungspfad. Browser oder API-Client, CDN oder Load Balancer, Service Mesh und Origin können unterschiedliche TLS-Stacks und Voreinstellungen besitzen. Wer das hybride Verfahren zu früh erzwingt, kann genau die Verbindungen blockieren, die geschützt werden sollen.

Kurzantwort: Führen Sie hybrides Post-Quanten-TLS schrittweise ein. Inventarisieren Sie jede TLS-Terminierung, aktualisieren Sie die Krypto-Bibliotheken, bevorzugen Sie X25519MLKEM768 zunächst mit klassischem Fallback, messen Sie Aushandlung und Fehler nach Client- und Origin-Klasse und erzwingen Sie das Verfahren erst in nachweislich kompatiblen Segmenten.

Was der neue Standard für Post-Quanten-TLS festlegt

Der im August 2026 veröffentlichte IETF-Standard RFC 10024 definiert drei hybride Schlüsselgruppen für TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024. Jede Gruppe kombiniert ML-KEM mit einem ephemeren Elliptic-Curve-Diffie-Hellman-Austausch. Laut Sicherheitsmodell bleibt der kombinierte Austausch geschützt, solange mindestens eine Komponente nicht gebrochen ist.

ML-KEM selbst ist ein Key Encapsulation Mechanism: Zwei Parteien bauen über einen öffentlichen Kanal ein gemeinsames Geheimnis auf. NIST FIPS 203 standardisiert dafür ML-KEM-512, -768 und -1024. Die Zahl benennt einen Parametersatz, nicht die Größe eines symmetrischen Schlüssels und auch keine TLS-Version.

Am 3. September 2026 hat die IETF außerdem die Beschreibung von reinem ML-KEM in TLS 1.3 als Informational RFC freigegeben. Die IESG-Mitteilung hält zugleich fest: Reines ML-KEM wird nicht für den allgemeinen Einsatz empfohlen; in vielen TLS-Implementierungen ist stattdessen die hybride Gruppe X25519MLKEM768 die Voreinstellung. Für Migrationen ist das eine wichtige Unterscheidung zwischen „implementiert“ und „allgemein empfohlen“.

Schlüsselaustausch und Zertifikate sind zwei getrennte Baustellen

TLS-FunktionAktueller MigrationspfadWas damit noch nicht gelöst ist
Vertraulichkeit des SitzungsschlüsselsHybrider Austausch wie X25519MLKEM768Authentizität von Server und Zertifikatskette
ServerauthentifizierungHeute meist klassische Zertifikatssignaturen; ML-DSA-Integration entwickelt sichBreite Browser-, CA- und PKI-Kompatibilität
Ende-zu-Ende-SchutzJede TLS-Strecke getrennt prüfenSchutz hinter einer terminierenden Edge oder einem Proxy
KryptoagilitätVersionierte Policies, austauschbare Bibliotheken und TelemetrieAutomatischer Beleg, dass jede Gegenstelle modern ausgehandelt hat

Ein hybrider Schlüsselaustausch schützt vor „heute speichern, später entschlüsseln“, wenn der Angreifer den verschlüsselten Verkehr jetzt aufzeichnet und künftig den klassischen Austausch brechen kann. Er macht eine klassische Zertifikatskette aber nicht post-quanten-sicher. Der Chromium-Fahrplan vom 27. Februar 2026 beschreibt die Post-Quanten-Authentifizierung deshalb als mehrstufige, langfristige Umstellung von Browsern, Zertifizierungsstellen und Servern.

Die IETF hat am 10. September 2026 auch die Verwendung von ML-DSA für TLS-1.3-Authentifizierung zur Veröffentlichung freigegeben. Das ist ein Protokollbaustein, aber noch kein Signal, klassische Web-PKI sofort abzuschalten. Ein realistischer Plan führt Schlüsselaustausch, Zertifikate, Vertrauensanker und Anwendungsprotokolle als getrennte Migrationsspuren.

Der Origin-Pfad entscheidet über Schutz und Verfügbarkeit

Bei einem CDN endet die Client-Verbindung an der Edge. Für nicht gecachte Inhalte entsteht eine zweite TLS-Verbindung vom Edge-System zum Origin. Post-Quanten-Schutz am Browser belegt daher nicht automatisch, dass auch der Origin-Pfad hybrid geschützt ist. Dasselbe gilt für API-Gateways, Ingress-Controller, Service-Mesh-Sidecars und ausgehende Dienstverbindungen.

Cloudflare berichtete am 8. September 2026 über eine neue automatische Auswahl der bevorzugten Schlüsselgruppe für Origin-Verbindungen. Im aktuell gescannten Origin-Kollektiv sank die vom Anbieter gemessene HelloRetryRequest-Rate von rund 52 auf 3,7 Prozent; 99,2 Prozent der post-quantenfähigen TLS-1.3-Verbindungen schlossen danach in einer Runde ab. Diese Anbietermessung belegt keinen universellen Wert für andere Netze, zeigt aber die operative Aufgabe: Fähigkeiten erkennen, richtig anbieten und den Effekt beobachten.

Ausfallrisiko: Wenn eine Policy ausschließlich X25519MLKEM768 zulässt, der Origin diese Gruppe aber nicht unterstützt, gibt es keinen gemeinsamen Algorithmus. Die TLS-1.3-Verbindung schlägt vollständig fehl. „Post-Quanten erzwingen“ darf deshalb erst nach einem positiven Kompatibilitätsnachweis erfolgen.

Entscheidungsmatrix für eine sichere ML-KEM-Migration

BetriebszustandSinnvolle PolicyFreigabekriterium
Unbekannte externe ClientsHybrid bevorzugen, klassischen Fallback zulassenFehler und Aushandlung nach Clientklasse sichtbar
Kontrollierte Service-zu-Service-StreckeHybrid auf beiden Seiten aktivieren; später erzwingenAlle Instanzen, Failover-Pfade und Rollbacks getestet
CDN zum eigenen OriginOrigin-Fähigkeit prüfen, danach hybrid bevorzugenKein Anstieg bei TLS-Fehlern oder Origin-Latenz
Legacy-Geräte oder eingebettete ClientsSeparates Segment und ÜbergangsfristUpgrade-, Gateway- oder Ablöseplan mit Eigentümer
Verbindliche Krypto-VorgabeNur freigegebene Gruppen erzwingenKompatibilitätsbeleg plus dokumentierte Ausnahme- und Notfallregel

Diese Matrix ist eine technische Orientierung, keine Zertifizierungs- oder Rechtsaussage. Ob ein hybrides Verfahren eine konkrete Vorgabe erfüllt, hängt unter anderem von freigegebenem Kryptomodul, Parameterwahl, Betriebsmodus und Prüfumfang ab.

Sieben Schritte für einen messbaren Post-Quanten-TLS-Pilot

  1. TLS-Terminierungen inventarisieren. Erfassen Sie Client, Edge, Load Balancer, Ingress, Mesh, Origin und ausgehende APIs als einzelne Verbindungen mit Owner, TLS-Bibliothek und Version.
  2. Schutzbedarf priorisieren. Beginnen Sie mit Daten, deren Vertraulichkeit über Jahre erhalten bleiben muss. Ein konkreter Aufbewahrungszeitraum ist belastbarer als eine spekulative Q-Day-Prognose.
  3. Bibliotheken und Gegenstellen prüfen. Belegen Sie die tatsächlich angebotenen und ausgehandelten Gruppen in einer Testumgebung. Produktname oder Lizenz allein reicht nicht.
  4. Hybrid zunächst bevorzugen. Aktivieren Sie X25519MLKEM768 mit kontrolliertem klassischem Fallback. Dokumentieren Sie Konfiguration, Version und den Weg zurück.
  5. Telemetrie trennen. Messen Sie Schlüsselgruppe, TLS-Version, HelloRetryRequest, Handshake-Fehler und -Latenz nach Client-, Region- und Origin-Klasse. Loggen Sie keine Geheimnisse oder vollständigen Nutzdaten.
  6. Fehlerfälle erzwingen. Testen Sie alte Clients, nicht aktualisierte Origins, Failover-Ziele, Zertifikatswechsel, Neustarts und Netzwerkgeräte, die größere Handshake-Nachrichten falsch behandeln könnten.
  7. Segmentweise verschärfen. Erzwingen Sie Hybridbetrieb erst auf kontrollierten Strecken. Definieren Sie Grenzwerte für automatischen oder manuellen Rollback und prüfen Sie den Rückweg regelmäßig.

Der Pilot gehört in ein Cloud- und DevOps-Betriebsmodell mit beobachtbaren Releases. Krypto-Inventar, Bedrohungsmodell und Ausnahmeprozess sind Teil des Cybersicherheitsdesigns. Für heterogene Plattformen ergänzt das Multi-Cloud-Kontrollmodell die Frage, wie eine einheitliche Schutzwirkung über verschiedene Produkte hinweg belegt wird.

Häufige Fragen zu Post-Quanten-TLS

Was ist hybrides Post-Quanten-TLS?

Es kombiniert in einem TLS-1.3-Schlüsselaustausch einen klassischen Algorithmus wie X25519 mit ML-KEM. Der gemeinsame Schlüssel bleibt geschützt, solange mindestens eine der beiden Komponenten sicher bleibt.

Ersetzt X25519MLKEM768 das TLS-Zertifikat?

Nein. Die Gruppe schützt den Schlüsselaustausch. Serverauthentifizierung und Zertifikatskette sind eine getrennte TLS-Funktion und können weiterhin auf klassischen Signaturen beruhen.

Sollte Post-Quanten-TLS sofort erzwungen werden?

Nur wenn alle relevanten Gegenstellen nachweislich kompatibel sind und eine verbindliche Vorgabe den Ausschluss klassischer Verfahren verlangt. Sonst ist bevorzugte hybride Aushandlung mit klassischem Fallback der sicherere Migrationspfad.

Welche Kennzahlen gehören in einen Pilot?

Mindestens ausgehandelte Schlüsselgruppe, TLS-Version, Handshake-Fehler, HelloRetryRequest-Rate, Handshake-Latenz, Client- und Origin-Klasse sowie erfolgreiche Fallbacks. Anwendungs- und Infrastrukturmetriken sollten getrennt auswertbar sein.

Quellen und Methodik

Dieser Beitrag trennt veröffentlichte Standards und Herstellerangaben von der ATMAN-Empfehlung für einen gestuften Pilot. Cloudflare-Zahlen sind anbieterspezifische Beobachtungen und wurden nicht unabhängig reproduziert. Abgerufen am 12. September 2026.