Wissen · TR-02102-2
ML-KEM-Hybride in TLS 1.3 nach TR‑02102‑2
Das BSI erlaubt drei hybride Post-Quanten-Gruppen für TLS 1.3. Browser schicken aber standardmäßig nur eine davon. Wer seinen Server nur nach der TR-Tabelle einstellt, bekommt mit Browsern keinen Post-Quanten-Schutz, sondern eine zusätzliche Runde im Handshake und eine klassische Schlüsseleinigung.
Stand: 30.10.2026 · Quellen: BSI TR-02102-2, Version 2026-01 vom 27.01.2026; BSI-Webseite zur TR-02102 (abgerufen am 26.10.2026); IANA-Register „TLS Supported Groups“ (abgeglichen am 28.10.2026); eigene Messung mit OpenSSL 3.5.7 am 30.10.2026
Warum hybrid, und warum jetzt
Wer heute verschlüsselten Verkehr mitschneidet, könnte ihn später mit einem ausreichend großen Quantencomputer entschlüsseln, wenn die Schlüsseleinigung rein klassisch war („jetzt speichern, später entschlüsseln“). Die TR-02102-2 zieht daraus eine Frist: Klassische Schlüsseleinigung allein ist nur noch bis Ende 2031 empfohlen (Abschnitt 3.1.3). Die Gruppen aus Tabelle 10 sollen ab 2032 nur noch hybrid genutzt werden (Abschnitte 3.4.2 und 3.6.1). Für TLS 1.2 erwartet das BSI keine standardisierte Post-Quanten-Schlüsseleinigung; auch deshalb ist TLS 1.2 nur bis 2031 empfohlen (Abschnitt 3.2, Tabelle 2).
„Hybrid“ heißt: Ein klassisches Verfahren (elliptische Kurve) und ML-KEM (FIPS 203) laufen nebeneinander, der Sitzungsschlüssel hängt von beiden ab. Bricht eines der beiden, schützt das andere weiter. Reines ML-KEM ohne klassischen Anteil nennt das BSI für TLS nicht.
Was das BSI erlaubt
In den Tabellen der Fassung 2026-01 stehen noch keine Hybridgruppen; Abschnitt 3.4.2 kündigt sie an. Auf seiner Webseite zur TR-02102 schreibt das BSI inzwischen: Der Standard ist als RFC 10024 erschienen, SecP256r1MLKEM768 und SecP384r1MLKEM1024 werden in der nächsten Fassung empfohlen und sind schon jetzt TR-konform in TLS 1.3 einsetzbar. Zusätzlich kann X25519MLKEM768 eingesetzt werden.
| Gruppe | IANA-Nr. (hex) | Bestandteile | Einordnung durch das BSI |
|---|---|---|---|
SecP256r1MLKEM768 | 4587 (0x11EB) | P-256 + ML-KEM-768 | in der nächsten TR-Fassung empfohlen, schon jetzt einsetzbar |
X25519MLKEM768 | 4588 (0x11EC) | X25519 + ML-KEM-768 | zusätzlich einsetzbar |
SecP384r1MLKEM1024 | 4589 (0x11ED) | P-384 + ML-KEM-1024 | in der nächsten TR-Fassung empfohlen, schon jetzt einsetzbar |
Die Nummern stammen nicht aus der TR, sondern aus dem IANA-Register. X25519 allein steht weiterhin nicht in Tabelle 10; als Teil von X25519MLKEM768 ist es laut BSI-Webseite zulässig (mehr dazu im Artikel X25519 und ChaCha20 in der TR-02102-2).
Was Browser tatsächlich schicken
Chrome und Edge (ab Version 131), Firefox auf dem Desktop (ab 132) und Safari (ab 26) bieten laut der Übersicht von Cloudflare standardmäßig X25519MLKEM768 an, zusammen mit klassischen Gruppen als Rückfall. Dass ein verbreiteter Browser die beiden SecP-Gruppen von sich aus anbietet, ist uns nicht bekannt. Auch OpenSSL 3.5 schickt als Client standardmäßig X25519MLKEM768 und X25519.
Daraus folgt: Die beiden Gruppen, die das BSI an erster Stelle nennt, kommen mit Browsern in der Praxis kaum zum Zug. Die Gruppe, die Browser nutzen, nennt das BSI „zusätzlich“.
Was wir gemessen haben
Wir haben am 30.10.2026 einen lokalen Testserver (openssl s_server, OpenSSL 3.5.7, nur TLS 1.3) mit verschiedenen Gruppenlisten aufgesetzt und mit openssl s_client verbunden. Der Client mit Standardeinstellung verhält sich wie ein aktueller Browser: Er schickt Schlüsselanteile für X25519MLKEM768 und X25519.
| Server bietet an | Client | Ergebnis |
|---|---|---|
| SecP384r1MLKEM1024, SecP256r1MLKEM768, secp384r1, secp256r1 | Standard | klassisch secp256r1, mit HelloRetryRequest (eine Runde mehr) |
| X25519MLKEM768, SecP384r1MLKEM1024, SecP256r1MLKEM768, secp384r1, secp256r1 | Standard | X25519MLKEM768, ohne Zusatzrunde |
| wie oben, X25519MLKEM768 an dritter Stelle | Standard | X25519MLKEM768, ohne Zusatzrunde |
| wie oben | nur SecP256r1MLKEM768 | SecP256r1MLKEM768 |
| wie oben | nur SecP384r1MLKEM1024 | SecP384r1MLKEM1024 |
| wie oben | X25519 und secp256r1 | klassisch secp256r1 |
| wie oben | nur X25519 | Abbruch (handshake_failure) |
Die erste Zeile ist der Fall, um den es geht: Der Server ist „nach Tabelle und BSI-Webseite“ eingestellt, und trotzdem endet der Handshake mit einem Browser-ähnlichen Client klassisch. Die Reihenfolge der Liste spielte in unserem Test kaum eine Rolle: OpenSSL nimmt bevorzugt eine Gruppe, für die der Client schon einen Schlüsselanteil geschickt hat. Entscheidend ist, ob X25519MLKEM768 überhaupt in der Liste steht.
Die Hybride machen den Handshake größer. Im Test war der ServerHello mit X25519MLKEM768 1.210 Byte groß, mit SecP384r1MLKEM1024 1.755 Byte, klassisch 155 Byte. Der ClientHello des Standardclients hatte 1.453 Byte und passt damit nicht mehr sicher in ein einzelnes Paket. Alte Firewalls oder Lastverteiler, die das nicht erwarten, sind die häufigste Fehlerquelle.
Empfehlung für die Konfiguration
Bieten Sie alle drei Hybridgruppen an, X25519MLKEM768 eingeschlossen, und behalten Sie klassische Gruppen aus Tabelle 10 als Rückfall für Clients ohne Post-Quanten-Unterstützung.
nginx (OpenSSL ab 3.5):
ssl_ecdh_curve X25519MLKEM768:SecP384r1MLKEM1024:SecP256r1MLKEM768:secp384r1:secp256r1;
Apache (2.4.x mit mod_ssl, OpenSSL ab 3.5):
SSLOpenSSLConfCmd Groups X25519MLKEM768:SecP384r1MLKEM1024:SecP256r1MLKEM768:secp384r1:secp256r1
Mit OpenSSL 3.0 bis 3.4 kennt die Bibliothek diese Namen nicht, und der Server startet mit dieser Zeile nicht. Prüfen Sie vorher openssl version und testen Sie mit nginx -t bzw. apachectl configtest. Die übrigen Zeilen (Protokolle, Suiten, Signaturverfahren) stehen im Artikel nginx und Apache nach TR-02102-2 konfigurieren.
Selbst prüfen
Mit OpenSSL ab 3.5 können Sie jede Gruppe einzeln anfragen:
openssl s_client -connect beispiel.de:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep "Negotiated TLS1.3 group"
openssl s_client -connect beispiel.de:443 -tls1_3 -groups SecP256r1MLKEM768 </dev/null 2>/dev/null | grep "Negotiated TLS1.3 group"
openssl s_client -connect beispiel.de:443 -tls1_3 -groups SecP384r1MLKEM1024 </dev/null 2>/dev/null | grep "Negotiated TLS1.3 group"
Steht dort die angefragte Gruppe, nimmt der Server sie an. Kommt keine Zeile, hat der Server abgelehnt. In Chrome zeigen die Entwicklerwerkzeuge unter „Sicherheit“ die ausgehandelte Gruppe der aktuellen Seite. Prüfen Sie nur eigene Server oder solche, für die Sie zuständig sind.
Grenzen
- Wir haben OpenSSL gemessen, nicht nginx, Apache oder einen bestimmten Browser. Andere Bibliotheken (BoringSSL, NSS, rustls, Java) können eine andere Auswahlregel haben.
- Sitzt vor dem Server ein Lastverteiler oder ein CDN, entscheidet dessen TLS-Stack. Was Ihre Konfigurationsdatei sagt, ist dann nicht, was Clients sehen.
- Die Browserversionen stammen aus einer Übersicht von Cloudflare, nicht aus eigener Messung. Prüfen Sie im Zweifel mit Ihren eigenen Clients.
- Das Zertifikat und seine Signatur bleiben klassisch. Hybride Schlüsseleinigung schützt die Vertraulichkeit mitgeschnittener Verbindungen, nicht die Authentisierung gegen einen künftigen Angreifer mit Quantencomputer.
Welche Gruppen Ihr Server von außen tatsächlich annimmt, alle drei Hybride eingeschlossen, misst der Bericht, mit Fundstelle je Zeile. Ein Beispiel ist der Musterbericht; alle Einträge der TR stehen auf der Seite TR-02102-2 als Tabelle. Für fünf Admins ist der Bericht in der Pilotphase kostenlos, gegen eine ehrliche Rückmeldung.
Quellen: BSI TR-02102 · IANA TLS Supported Groups · Cloudflare: Post-quantum support. Dieser Artikel ist keine Rechtsberatung und nicht vom BSI geprüft. Er fasst die genannten Quellen in eigenen Worten zusammen. Die Konfigurationszeilen sind Beispiele; testen Sie sie vor dem Einsatz in Ihrer Umgebung.