Was ML-KEM (FIPS 203) im TLS-Handshake verändert
ML-KEM steht für Module-Lattice-Based Key-Encapsulation Mechanism und ist der erste von der NIST finalisierte Post-Quanten-Standard für den Schlüsselaustausch, veröffentlicht als FIPS 203 im August 2024 (NIST FIPS 203). Er geht aus dem Verfahren CRYSTALS-Kyber hervor. Ein KEM ist kein Signaturverfahren: Es kapselt ein gemeinsames Geheimnis, aus dem beide Seiten denselben Sitzungsschlüssel ableiten. Genau dieser Schlüsselaustausch schützt die Vertraulichkeit einer TLS-Verbindung und ist deshalb das erste Ziel der Post-Quanten-Migration.
Die Größen sind der entscheidende Unterschied zur klassischen Kryptografie. ML-KEM-768, die im Web dominierende Parametrisierung, arbeitet mit einem Encapsulation Key von 1184 Byte, einem Ciphertext von 1088 Byte und einem gemeinsamen Geheimnis von 32 Byte (NIST FIPS 203). Im Handshake legt der Client seinen 1184 Byte großen Encapsulation Key in die key_share-Extension der ClientHello, der Server kapselt dagegen und schickt den 1088 Byte großen Ciphertext zurück. Zum Vergleich: Eine klassische X25519-Kurve belegt im key_share gerade einmal 32 Byte.
Sowohl der IETF-Entwurf als auch das BSI empfehlen ausdrücklich den hybriden Betrieb (IETF draft-ietf-tls-ecdhe-mlkem). X25519MLKEM768 kombiniert die klassische Kurve X25519 mit ML-KEM-768: Solange kein kryptografisch relevanter Quantencomputer existiert, trägt X25519 die Sicherheit; taucht einer auf, übernimmt ML-KEM. Ein Angreifer müsste beide Verfahren gleichzeitig brechen. Der Client sendet also 32 Byte X25519 plus 1184 Byte ML-KEM, zusammen rund 1216 Byte im key_share (NIST FIPS 203).
2026: Standard in Chrome, Firefox und auf Apple-Plattformen
Der Umbruch kam schneller als viele erwartet hatten. Chrome liefert den standardisierten hybriden Schlüsselaustausch seit Chrome 131 (November 2024) als Voreinstellung aus, Firefox aktivierte X25519MLKEM768 mit Firefox 132 für HTTPS und ab Firefox 135 auch für QUIC. Apple ergänzte die systemweite Unterstützung in iOS 26 und macOS Tahoe 26 im Herbst 2025. Zusätzlich haben verbreitete TLS-Bibliotheken wie OpenSSL und die Go-Standardbibliothek den Mechanismus übernommen (Measurement Study of Post-Quantum Readiness of the Internet 2026).
| Plattform | Hybrid standardmäßig aktiv | Umfang |
|---|---|---|
| Chrome | ab Version 131 (Nov 2024) | HTTPS, später auch QUIC |
| Firefox | ab Version 132 | HTTPS, QUIC ab Firefox 135 |
| Apple (iOS/macOS) | iOS 26 / macOS Tahoe 26 | systemweit, Herbst 2025 |
| OpenSSL, Go u. a. | 2024-2025 | hybrider X25519MLKEM768 |
Das Ergebnis dieser Vorentscheidung ist messbar: Über 50 % des menschlich erzeugten TLS-Traffics zu Cloudflare nutzte bereits Ende Oktober 2025 den hybriden X25519MLKEM768-Schlüsselaustausch (Cloudflare Radar). Weil die Browser den Post-Quanten-Key-Share von sich aus anbieten, entscheidet allein der Server, ob die Verbindung hybrid oder klassisch zustande kommt. Wer TLS 1.3 sauber betreibt, ist damit oft schon weiter, als er denkt. Ein Blick auf den Unterschied zwischen TLS 1.2 und TLS 1.3 macht klar, warum die Protokollversion die Grundvoraussetzung ist.
Der 1,2-KB-Key-Share: Warum ältere Server-Stacks scheitern
Post-Quanten-Kryptografie ist nicht kostenlos. Der hybride key_share wächst von 32 Byte auf rund 1216 Byte, und mit ihm die gesamte ClientHello: Statt weniger hundert Byte verlässt nun eine ClientHello von deutlich über 1,5 KB den Browser. Damit passt sie nicht mehr in ein einzelnes Netzwerkpaket. Genau hier zeigt sich die sogenannte Ossifikation des Protokolls: Manche Middleboxen, Load-Balancer und ältere TLS-Bibliotheken nehmen stillschweigend an, dass eine ClientHello immer in ein Paket passt, und verwerfen alles, was diese Annahme verletzt (Cloudflare Radar).
Klassisch X25519: 32 Byte im key_share. Hybrid X25519MLKEM768: 32 Byte X25519 plus 1184 Byte ML-KEM-768-Encapsulation-Key ergibt rund 1216 Byte im Client-key_share. Die Server-Antwort besteht aus dem 1088 Byte großen ML-KEM-Ciphertext plus 32 Byte X25519, zusammen rund 1120 Byte (NIST FIPS 203). Das ist der Punkt, an dem unflexible Server- und Netzwerkkomponenten die Verbindung abreißen.
Wie real dieses Risiko ist, zeigt ein frühes Experiment: Als Browser testweise Post-Quanten-Schlüssel ähnlicher Größe direkt in der ClientHello mitschickten, brachen rund 0,05 % der Verbindungen ab, weil einzelne Komponenten die größere Nachricht nicht verarbeiten konnten (Cloudflare Radar). Das klingt wenig, summiert sich bei Millionen Verbindungen aber zu spürbaren Ausfällen. Die typischen Fehlerbilder:
- Handshake-Abbruch bei großer ClientHello: Middleboxen oder WAFs verwerfen Pakete, die nicht in ein Segment passen, und der Browser fällt auf eine Fehlerseite zurück.
- Versions-Intoleranz: Ältere Stacks reagieren auf unbekannte
key_share-Gruppen mit einem Downgrade auf TLS 1.2 statt mit einem sauberen HelloRetryRequest. - MTU- und Fragmentierungsprobleme: Restriktive Netzwerkpfade fragmentieren die größere ClientHello nicht korrekt, was zu Timeouts führt.
- Fehlkonfigurierte Load-Balancer: TLS-terminierende Proxys ohne Update auf hybride Gruppen ignorieren den Post-Quanten-Anteil oder brechen ab.
Die Browser-Hersteller haben aus den frühen Ausfällen gelernt und den Rollout schrittweise gestaltet: erst als Opt-in-Experiment, dann als Standard, begleitet von Telemetrie über abgebrochene Handshakes. Für Website-Betreiber verlagert sich die Verantwortung damit auf die eigene Infrastruktur. Ein Server, der die größere ClientHello sauber verarbeitet, profitiert ohne Zutun; ein veralteter Stack fällt still aus dem hybriden Schutz heraus, ohne dass eine Fehlermeldung darauf hinweist.
Auch das Transportprotokoll spielt mit: Bei QUIC und HTTP/3 liegt der Handshake in UDP-Datagrammen, wo die größere ClientHello andere Fragmentierungsregeln trifft als bei TCP. Wer beide Protokolle anbietet, sollte beide Pfade prüfen.
Harvest now, decrypt later: die Bedrohung läuft bereits
Der Grund für die Eile ist nicht der Quantencomputer von morgen, sondern der Datendiebstahl von heute. Beim Angriffsmuster harvest now, decrypt later zeichnen Angreifer verschlüsselten Datenverkehr bereits jetzt auf und speichern ihn, um ihn zu entschlüsseln, sobald ein ausreichend leistungsfähiger Quantencomputer verfügbar ist. Betroffen ist alles, was lange vertraulich bleiben muss: Gesundheitsdaten, Verträge, geistiges Eigentum, Zugangsdaten. Weil nur der Schlüsselaustausch die rückwirkende Vertraulichkeit schützt, ist er der dringlichste Baustein der Migration.
Das BSI hat die Konsequenz im Februar 2026 unmissverständlich formuliert: Migrationspläne müssen nicht nur erstellt, sondern jetzt umgesetzt werden (BSI, Migration zu Post-Quanten-Kryptografie). Als Fristen nennt die Behörde das Ende 2030 für besonders schutzbedürftige Daten und Ende 2031 für den allgemeinen Betrieb. Da eine vollständige Umstellung erfahrungsgemäß fünf bis zehn Jahre dauert, bleibt für den Start kaum Zeit. Wer die Verschlüsselung des Mailverkehrs absichert, findet die gleiche Logik im Beitrag zu MTA-STS und TLS-RPT für verschlüsselten Mailtransport wieder.
Post-Quanten-Verfahren sollen zunächst nur in Kombination mit klassischen Verfahren eingesetzt werden. Solange kein Quantencomputer existiert, schützt das klassische Verfahren; steht einer zur Verfügung, schützt das quantenresistente Verfahren.
— BSI, Migration zu Post-Quanten-Kryptografie (sinngemäß)
Wie post-quantum-bereit das Internet wirklich ist
Eine breit angelegte Messstudie hat 2026 den Ist-Zustand erhoben. Über 32.011 Domains wurden die real ausgehandelten TLS-Parameter analysiert, von der Protokollversion über die Cipher Suite bis zum Schlüsselaustausch (Measurement Study of Post-Quantum Readiness of the Internet 2026). Das Bild ist zweigeteilt: Die eine Hälfte hat den Sprung geschafft, die andere nicht.
Knapp die Hälfte der Domains unterstützt einen hybriden Post-Quanten-Schlüsselaustausch wie ML-KEM-768 mit X25519 (Measurement Study 2026).
Die Mehrheit der übrigen Domains setzt weiterhin ausschließlich auf klassischen Schlüsselaustausch und bleibt damit anfällig für harvest now, decrypt later (Measurement Study 2026).
Nur gut die Hälfte der Domains verhandelt standardmäßig TLS 1.3, die Grundvoraussetzung für den hybriden Schlüsselaustausch (Measurement Study 2026).
Ein erheblicher Anteil, besonders in Banken und Behörden, verlässt sich noch auf TLS 1.2 ohne Post-Quanten-Option (Measurement Study 2026).
Bemerkenswert ist das Gefälle zwischen den Branchen. Gerade Sektoren mit besonders schutzbedürftigen Daten, etwa Banken und Behörden, hängen bei der Modernisierung hinterher: Ihr überdurchschnittlicher Anteil an TLS 1.2 bedeutet, dass sie den hybriden Schlüsselaustausch technisch noch gar nicht anbieten können (Measurement Study of Post-Quantum Readiness of the Internet 2026). Ausgerechnet dort, wo harvest now, decrypt later das größte Schadenspotenzial hat, ist der Rückstand am deutlichsten. Für Betreiber in regulierten Branchen erhöht das den Handlungsdruck, denn die BSI-Fristen gelten unabhängig vom aktuellen Modernisierungsgrad.
Auf der Infrastrukturseite treiben die großen CDNs die Zahlen: Cloudflare taucht in der Studie als sichtbarster Post-Quanten-fähiger Anbieter auf und deckt einen erheblichen Teil der hybriden Verbindungen ab (Measurement Study 2026). Für viele KMUs bedeutet das: Liegt die Website hinter einem modernen CDN oder Reverse Proxy, ist der hybride Schlüsselaustausch oft ohne eigenes Zutun aktiv. Wer direkt ausliefert, muss den Server-Stack selbst aktualisieren.
Die Authentifizierungs-Lücke: Schlüsselaustausch ja, Zertifikate nein
Ein Befund der Messstudie verdient besondere Aufmerksamkeit: Während fast die Hälfte der Domains bereits hybrid Schlüssel austauscht, lag die Verbreitung hybrider Post-Quanten-Zertifikate bei 0 % (Measurement Study 2026). Die Authentifizierung läuft nach wie vor über klassische Signaturen: 54,05 % der untersuchten Domains nutzen RSA mit SHA-256, 42,32 % ECDSA mit SHA-256 (Measurement Study 2026). Post-Quanten-Signaturen wie ML-DSA (FIPS 204) oder SLH-DSA (FIPS 205) sind in der Praxis noch nicht angekommen.
Der Schlüsselaustausch schützt rückwirkend gegen harvest now, decrypt later und hat deshalb Priorität. Die Signaturebene, also die Zertifikatskette, ist erst dann angreifbar, wenn ein Quantencomputer live fälschen kann, nicht rückwirkend. Deshalb ist die Reihenfolge sinnvoll: erst KEM, dann Signaturen. Wer die Ausstellung neuer Zertifikate im Blick behalten will, findet im Certificate-Transparency-Monitoring das passende Frühwarnsystem.
Für Betreiber heißt das nicht, die Signaturebene zu ignorieren, sondern Krypto-Agilität aufzubauen: Systeme so gestalten, dass sich Verfahren austauschen lassen, ohne die gesamte Architektur umzubauen. Genau das empfiehlt das BSI als Kernprinzip der Migration (BSI, Migration zu Post-Quanten-Kryptografie). Wer heute Zertifikate und Schlüssel sauber automatisiert, kann PQ-Signaturen später mit geringem Aufwand nachziehen.
So prüfen Sie Ihre Post-Quantum-Readiness
Post-Quantum-Readiness ist kein einmaliger Haken, sondern ein Zustand, der sich mit jedem Server-Update, jedem CDN-Wechsel und jeder Konfigurationsänderung verschieben kann. Diese Schritte geben einen belastbaren Ausgangsbefund:
- TLS 1.3 sicherstellen: Ohne TLS 1.3 gibt es keinen hybriden Schlüsselaustausch. Prüfen Sie, ob Ihr Server TLS 1.3 anbietet und TLS 1.2 nur als Fallback, nicht als Standard, dient.
- Hybride Gruppe prüfen: Kontrollieren Sie, ob Ihr Server X25519MLKEM768 in den unterstützten Gruppen führt und bei einem modernen Browser tatsächlich aushandelt.
- Große ClientHello testen: Stellen Sie sicher, dass Middleboxen, WAF und Load-Balancer eine ClientHello über 1,5 KB verarbeiten, ohne die Verbindung abzureißen.
- Downgrade-Verhalten kontrollieren: Ein Server, der bei einer unbekannten Gruppe stillschweigend auf TLS 1.2 zurückfällt, verliert den Post-Quanten-Schutz unbemerkt.
- QUIC-Pfad separat prüfen: Wenn Sie HTTP/3 anbieten, testen Sie den hybriden Handshake auch über UDP, wo andere Fragmentierungsregeln gelten.
- Kontinuierlich überwachen: Ein einmaliger Test veraltet. Verankern Sie die Prüfung von Protokoll, Cipher-Konfiguration und Zertifikat in einem laufenden Monitoring.
Die gleiche Sorgfalt, die bei der Chrome-HTTPS-Pflicht ab Oktober 2026 gefragt ist, gilt für die Post-Quanten-Konfiguration: Beides scheitert selten am fehlenden Willen, sondern an unbemerkten Konfigurationslücken. Ein kontinuierliches SSL-Zertifikats-Monitoring bildet dafür die Grundlage.
TLS-Konfiguration kontinuierlich überwachen
Der wirksamste Schutz gegen stille Downgrades ist Sichtbarkeit. Der Security-Scan von XICTRAQ prüft die TLS- und Handshake-Konfiguration Ihrer Website fortlaufend: unterstützte Protokollversionen, Cipher-Konfiguration, Zertifikatsgültigkeit und die HTTP-Security-Header inklusive HSTS. Fällt eine Verbindung von TLS 1.3 auf TLS 1.2 zurück, verschwindet eine sichere Cipher Suite aus der Konfiguration oder nähert sich ein Zertifikat dem Ablauf, schlägt das Monitoring an, bevor Besucher oder Auditoren es bemerken.
Weil die Prüfung an jeden Uptime-Check gekoppelt ist, entsteht ein durchgehendes Bild statt einer Momentaufnahme. Änderungen an der TLS-Konfiguration, etwa nach einem Server-Update oder einem CDN-Wechsel, werden als Abweichung erkannt und über Ihre Alerting-Kanäle gemeldet, sei es per E-Mail, Slack, Discord oder Telegram. So bleibt die Post-Quanten-Bereitschaft nicht dem Zufall überlassen, sondern wird zu einem überwachten Zustand. Ergänzend erkennt das DNSSEC-Monitoring Manipulationen an der Namensauflösung, die einen sicheren Handshake unterlaufen würden.
Was Betreiber jetzt konkret tun sollten
Die gute Nachricht: Für die meisten Website-Betreiber ist der erste Schritt kleiner als befürchtet. Diese Checkliste bringt Sie in eine belastbare Ausgangsposition:
- Server-Stack aktualisieren: TLS-Bibliothek und Webserver auf eine Version bringen, die X25519MLKEM768 unterstützt.
- CDN-Einstellungen prüfen: Falls ein CDN oder Reverse Proxy im Einsatz ist, den hybriden Schlüsselaustausch dort aktivieren oder bestätigen.
- Middleboxen und Load-Balancer testen: Sicherstellen, dass große ClientHellos über 1,5 KB unverändert durchgereicht werden.
- Krypto-Agilität verankern: Zertifikats- und Schlüsselverwaltung so automatisieren, dass Verfahren austauschbar bleiben, wie es das BSI empfiehlt (BSI, Migration zu Post-Quanten-Kryptografie).
- Manipulationen erkennen: Unerwartete Änderungen an Inhalten und Konfiguration früh bemerken, etwa mit den Methoden aus dem Beitrag zu Defacement-Angriffen erkennen und melden.
- Dauerhaft überwachen: Protokoll, Cipher-Konfiguration und Zertifikat in ein laufendes Monitoring aufnehmen, statt sich auf einen einmaligen Test zu verlassen.
Dieser Artikel stützt sich auf: NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism, ML-KEM), IETF draft-ietf-tls-ecdhe-mlkem (hybrider ECDHE-/ML-KEM-Schlüsselaustausch für TLS 1.3), BSI (Migration zu Post-Quanten-Kryptografie, Handlungsempfehlungen), die Measurement Study of Post-Quantum Readiness of the Internet 2026 (arXiv) sowie Cloudflare Radar (State of the Post-Quantum Internet). Zahlen geben den Stand der jeweiligen Veröffentlichung wieder.
Häufige Fragen zu Post-Quantum-TLS und ML-KEM
Muss ich als KMU sofort auf ML-KEM umstellen?
Ist mein Server unsicher, wenn er noch klassisch verschlüsselt?
Warum brechen manche Verbindungen durch den größeren Key-Share ab?
Was ist der Unterschied zwischen ML-KEM und einem Post-Quanten-Zertifikat?
Reicht es, ML-KEM allein statt hybrid zu nutzen?
Wie erkenne ich, ob meine TLS-Konfiguration sich unbemerkt verschlechtert?
Post-Quantum-Bereitschaft als Daueraufgabe
Der Wechsel zu ML-KEM ist kein Stichtag, sondern ein fortlaufender Prozess. Die Browser haben den ersten Schritt getan und bieten den hybriden Schlüsselaustausch von sich aus an, die großen CDNs erzwingen ihn an der Kante, und die BSI-Fristen setzen den Rahmen. Was bleibt, ist die Aufgabe, die eigene TLS-Konfiguration bereit zu machen und bereit zu halten. Wer heute den Server-Stack aktualisiert, Middleboxen testet und Krypto-Agilität aufbaut, ist auf die Post-Quanten-Ära vorbereitet, ohne in Hektik zu verfallen. Der Security-Scan von XICTRAQ übernimmt die laufende Kontrolle und meldet Downgrades, bevor sie zum Problem werden.