TLS 1.3: Quanten-Schwachstellen und hybride Gegenmaßnahmen

Typ:Technischer Artikel
Veröffentlicht:August 2025
Schlüsselwörter: TLS 1.3, Post-Quanten-Kryptographie, Hybrides KEM, ML-KEM-768, X25519, RSA

Zusammenfassung

Transport Layer Security (TLS) Version 1.3 schützt unsere Internetkommunikation durch Vertraulichkeit und Integrität mittels elliptischer-Kurven-Diffie–Hellman-Schlüsselaustausch und digitaler Signaturen. Aber hier ist das Problem: Beide Verfahren beruhen auf mathematischen Problemen—Ganzzahlfaktorisierung und diskretem Logarithmus—die durch Quantenalgorithmen angreifbar werden. Dadurch entsteht ein Zeitbomben-Szenario, in dem Gegner heute verschlüsselten Verkehr mitschneiden und später entschlüsseln können, sobald kryptographisch relevante Quantencomputer Realität sind. In diesem Artikel erläutern wir die Bedrohung, zeigen, wie der neu standardisierte hybride Schlüsselaustausch ML-KEM-768 + X25519 Schutz bietet, und erklären, warum klassische RSA-Signaturen für die Authentifizierung von TLS 1.3-Sitzungen weiterhin gut geeignet sind.

Wichtigste Punkte auf einen Blick

Die klassischen Grundlagen von TLS 1.3

Zunächst zum Status quo: Wenn ein Browser eine sichere Website aufruft, führt er mit dem Server einen elliptischen Diffie–Hellman-Austausch durch, um ein gemeinsames Geheimnis zu erzeugen. Anschließend authentifizieren beide Seiten diesen Austausch über X.509-Zertifikate, wie in RFC 8446 beschrieben. Der Vorteil der ECDH-Operation (häufig mit der Kurve X25519) ist die Vorwärtsgeheimnis: Selbst wenn morgen der private Schlüssel des Servers geleakt wird, kann der heutige Verkehr nicht entschlüsselt werden. Die Authentifizierung erfolgt über digitale Signaturen—typischerweise RSA oder ECDSA—im Serverzertifikat, sodass der Browser die Gegenstelle prüfen kann.

Ablauf des TLS 1.3-Handshakes
Client
💻
ClientHello • Unterstützte Gruppen (X25519) • KeyShare
ServerHello • Ausgewählte Gruppe • KeyShare
{Encrypted Extensions} • Certificate • CertificateVerify (RSA/ECDSA) • Finished
{Finished}
🔒 Anwendungsdaten
Server
🖥️
Abbildung 1: Standard-TLS-1.3-Handshake mit Schlüsselaustausch und Authentifizierung. Die verschlüsselten Anteile (grün dargestellt) beginnen nach der Schlüsselableitung.

Die Sicherheit beider Mechanismen hängt von Problemen ab, die wir für schwer halten: Diffie–Hellman vom diskreten Logarithmus, RSA von der Faktorisierung großer Zahlen. Ein ausreichend leistungsfähiger Quantencomputer mit Shors Algorithmus könnte diese Probleme effizient lösen, wie NISTs Risikoanalyse ausführt. Obwohl solche Maschinen noch nicht existieren, warten staatliche Akteure nicht ab—sie zeichnen bereits verschlüsselte Daten auf in der Hoffnung, sie am „Q-Day“ entschlüsseln zu können.

Quantenbedrohungen und das „Harvest-Now-Decrypt-Later“-Problem

HNDL klingt nach Spionagethriller, ist aber eine reale Sorge der IT-Sicherheit. Das Prinzip: Auch wenn heutige Quantencomputer moderne Kryptographie nicht brechen, können Angreifer verschlüsselte Verbindungen abfangen und speichern oder ganze Datenbanken entwenden—ein Archiv verschlüsselter Geheimnisse, das auf den Tag wartet, an dem Quantenrechner stark genug sind.

Zeitlinie eines Harvest-Now-Decrypt-Later-Angriffs
2024
📡
Sammelphase
Angreifer fangen TLS-Verkehr ab und speichern ihn
🔒 Verschlüsselte Daten 🔒 Sitzungsschlüssel 🔒 Zertifikate
2024-203X
💾
Speicherphase
Archivierung, bis Quantencomputer verfügbar sind
🗄️ Verschlüsselte Archive
203X+
⚛️
Entschlüsselungsphase
Quantencomputer brechen klassische Kryptographie
📄 Klartext 🔑 Private Schlüssel 🔓 Geheimnisse offengelegt
Abbildung 2: Drei Phasen eines HNDL-Angriffs. Heute befinden sich Gegner höchstwahrscheinlich in der Sammelphase und legen Archive an.

Branchenanalysen warnen, dass Angreifer mit hinreichend starken Quantenrechnern aus aufgezeichneten Handshakes private Schlüssel extrahieren und Jahre an Daten entschlüsseln könnten, wie auch der IETF-Entwurf zu PQC-Anwendungen beschreibt.

Besonders kritisch ist das für Informationen mit langem Schutzbedarf—etwa Finanzunterlagen, Betriebsgeheimnisse, medizinische Historien oder behördliche Verschlusssachen. Wer Daten über 10–20 Jahre vertraulich halten muss, sollte jetzt handeln.

Tabelle 1: Vergleich kryptographischer Verfahren gegen klassische und Quantenbedrohungen
Verfahren Typ Schlüsselgröße Klassische Sicherheit Quantensicherheit Status
RSA-2048 Signatur/KEM 256 Byte ✅ Stark ❌ Durch Shor angreifbar Aktueller Standard
X25519 Schlüsselaustausch 32 Byte ✅ Stark ❌ Durch Shor angreifbar Aktueller Standard
ML-KEM-768 KEM 1.184 Byte ✅ Stark ✅ Resistent NIST FIPS 203
X25519 + ML-KEM-768 Hybrides KEM 1.216 Byte ✅ Stark ✅ Resistent Empfohlen
ML-DSA-65 Signatur 1.952 Byte ✅ Stark ✅ Resistent NIST FIPS 204

Daher priorisiert die Community derzeit quantensicheren Schlüsselaustausch vor quantensicheren Signaturen. Der Schlüsselaustausch muss Vertraulichkeit über die Lebensdauer der Verbindung hinaus sicherstellen, während Signaturen nur zum Zeitpunkt der Verifikation wirken. Wird eine Signatur erst in zehn Jahren gebrochen, kompromittiert das nicht die damals ausgetauschten Daten.

Hybrider Schlüsselaustausch mit ML-KEM-768 und X25519

Post-Quanten-Kryptographie (PQC) ist eine neue Generation von Verfahren, die sowohl klassischen als auch Quantenangriffen standhalten sollen. Dazu zählt ML-KEM (früher Kyber), ein gitterbasiertes Key-Encapsulation-Mechanism, das NIST in FIPS 203 standardisiert hat. Anstatt Bewährtes zu verwerfen, schlägt die IETF einen hybriden Ansatz vor, der klassische und PQC-Verfahren kombiniert.

Hybrider Schlüsselaustausch: X25519 + ML-KEM-768
Client
X25519
32 Byte
🔑
+
ML-KEM-768
1.184 Byte
🛡️
Schlüsselaustausch
• ECDH-Berechnung • KEM-Kapselung
Server
X25519
32 Byte
🔑
+
ML-KEM-768
1.184 Byte
🛡️
Geheimnisse kombinieren (KDF)
🔐 Hybrider Sitzungsschlüssel Gegen klassische und Quantenangriffe abgesichert
Abbildung 3: Der hybride Austausch kombiniert X25519 mit ML-KEM-768. Beide Geheimnisse werden getrennt abgeleitet und über eine KDF zu einem Sitzungsschlüssel zusammengeführt.

Die Gruppe X25519MLKEM768 steht exemplarisch für diesen „Gürtel-und-Hosenträger“-Ansatz. Sie kombiniert einen X25519‑öffentlichen Schlüssel mit einem ML‑KEM‑768‑öffentlichen Schlüssel, wie in der IETF‑Spezifikation beschrieben. Während des Handshakes führen Client und Server zwei Operationen aus: einen klassischen Diffie‑Hellman‑Austausch über elliptische Kurven und eine ML‑KEM‑Kapselung. Anschließend werden beide Geheimnisse (meist mittels kryptographischer Hashfunktion) kombiniert, um den Sitzungsschlüssel herzuleiten. Der Clou: Falls Quantencomputer X25519 eines Tages brechen, schützt ML‑KEM weiterhin. Und falls Forschende eine Schwäche in ML‑KEM finden, springt X25519 ein. Wie Sicherheitsexperten betonen, müsste man beide Algorithmen brechen, um die Sitzung zu kompromittieren.

In der Kryptographie gibt es keinen „Free Lunch“: Die Einführung hybrider KEMs bringt praktische Hürden mit sich. Laut NIST FIPS 203 umfasst ein ML‑KEM‑768‑öffentlicher Schlüssel 1.184 Byte. Zusammen mit den 32 Byte von X25519 ergibt das im ClientHello etwa 1.216 Byte (siehe unsere Demo‑Seite für Details).

ClientHello: Größenvergleich
Klassisch (nur X25519)
32 Byte
Hybrid (X25519 + ML‑KEM‑768)
32 B
1.184 B
Insgesamt 1.216 Byte
⚠️ Die 38‑fache Vergrößerung kann Paketfragmentierung auslösen oder Middleboxes verwirren
Abbildung 4: Der hybride Ansatz vergrößert den Handshake deutlich und kann bei mancher Netzinfrastruktur zu Kompatibilitätsproblemen führen.

Diese Zunahme kann Kopfschmerzen bereiten—Akamais Untersuchung zeigt, dass sie Paketfragmentierung begünstigen oder ältere Netzausrüstung, die kleinere Handshakes erwartet, verwirren kann. Trotz dieser Anlaufschwierigkeiten bewegt sich die Branche schnell: Große Cloud‑Anbieter, CDNs und TLS‑Bibliotheken rollen bereits Unterstützung für hybride Gruppen aus.

Digitale Signaturen – warum RSA weiterhin ausreicht

Während der Schlüsselaustausch die Vertraulichkeit schützt, übernehmen digitale Signaturen in TLS die Authentifizierung. Der Ablauf: Der Server weist seine Identität nach, indem er das Handshake‑Protokoll signiert; der Client prüft diese Signatur mit dem öffentlichen Schlüssel aus dem Serverzertifikat. Entscheidend ist: Das geschieht im initialen Handshake, bevor sensible Daten übertragen werden.

Warum RSA‑Signaturen (vorerst) genügen
🔴 Schlüsselaustausch (verwundbar)
Heute
ECDH‑Schlüsselaustausch
🔒 Verschlüsselte Daten
Zukunft (Q‑Day)
ECDH mit Shor brechen
🔓 Daten entschlüsselt!
❌ Vergangene Sitzungen kompromittiert
🟢 Signatur (sicher)
Heute
RSA‑Signatur geprüft
✅ Authentifizierung abgeschlossen
Zukunft (Q‑Day)
RSA mit Shor brechen
🤷 Zu spät für frühere Sitzungen
✅ Vergangene Sitzungen bleiben geschützt
Abbildung 5: Das spätere Brechen einer Signatur kompromittiert keine früheren Sitzungen—anders als das Brechen des Schlüsselaustauschs, das alle verschlüsselten Daten offenlegt.

Diese zeitliche Abfolge ist entscheidend: Wie Cloudflares Analyse zeigt, ermöglicht selbst das spätere Faktorisieren eines RSA‑Schlüssels keine nachträgliche Kompromittierung von Sitzungen, die einen sicheren Schlüsselaustausch verwendeten.

Darum sind PQ‑Signaturen nicht dringend nötig, um die „Harvest‑Now‑Decrypt‑Later“-Bedrohung zu adressieren. Ein RSA‑2048‑ oder ECDSA‑P256‑Zertifikat mit angemessener Laufzeit (z. B. ein Jahr) bietet für heutige Zwecke ausreichend Sicherheit. Allerdings dürfen wir Root‑Zertifizierungsstellen nicht ignorieren, deren Zertifikate oft zwanzig Jahre oder länger gültig sind, wie dieser IETF‑Entwurf betont. Treffen Quantencomputer während dieser Gültigkeit ein, könnten Angreifer die CA imitieren und Scheinzertifikate ausstellen.

Für solche Hochrisiko‑Szenarien werden bereits PQ‑Signaturverfahren wie ML‑DSA (Dilithium) und SLH‑DSA (SPHINCS+) sondiert. Diese Verfahren bringen jedoch Trade‑offs mit sich—größere Schlüssel und Signaturen sowie derzeit spürbare Performanceeinbußen. Die Einführung wird voraussichtlich schrittweise erfolgen, wenn Implementierungen reifen und Hardware nachzieht.

Sinnvoll ist derzeit: Zertifikatslaufzeiten kurz halten, den Fortschritt bei PQC‑Signaturen beobachten und die eigene Infrastruktur so auslegen, dass sie neue Algorithmen aufnehmen kann. Durch die Kombination aus hybridem Schlüsselaustausch (für langfristige Vertraulichkeit) und etablierten Signaturen (für die aktuelle Authentifizierung) erreichen wir einen robusten Schutz gegen Quantenbedrohungen, ohne die heute nötige Performance und Kompatibilität einzubüßen.

📋 Schnelle Implementierungs‑Checkliste

  • ✅ Hybride Gruppen (X25519MLKEM768) in der TLS‑Konfiguration aktivieren
  • ✅ Auf Paketfragmentierung und Middlebox‑Kompatibilität testen
  • ✅ Zertifikatslaufzeiten kurz halten (≤ 1 Jahr für Endentitäts‑Zertifikate)
  • ✅ NIST‑ und IETF‑Fortschritt bei PQC‑Signaturen beobachten
  • ✅ Systeme mit langfristig sensiblen Daten für priorisierte Migration inventarisieren
  • ✅ Infrastruktur‑Updates für größere Handshakes einplanen