So prüfen Sie, ob Ihre Website Post-Quanten-TLS unterstützt

Eine Website ist für den heute wichtigsten Teil Post-Quanten-bereit, wenn ihr Server Sitzungsschlüssel über eine hybride Post-Quanten-Schlüsseleinigung vereinbaren kann. Die am weitesten verbreitete Option ist X25519MLKEM768. Sie kombiniert das klassische X25519 mit ML-KEM-768, dem von NIST in FIPS 203 standardisierten Schlüsselkapselungsverfahren (Key Encapsulation Mechanism). Die IANA hat sie als TLS-Gruppe 0x11EC registriert, und sie ist die einzige Post-Quanten-Gruppe, die die IANA als empfohlen kennzeichnet.

Warum zuerst die Schlüsseleinigung? Wegen Harvest Now, Decrypt Later: Ein Angreifer kann verschlüsselten Datenverkehr heute aufzeichnen und ihn entschlüsseln, sobald ein leistungsfähiger Quantencomputer existiert. Nur die Schlüsseleinigung schützt aufgezeichneten Datenverkehr. Zertifikate und Signaturen sind ebenfalls wichtig, doch eine Signatur muss in Echtzeit gefälscht werden, daher können sie später migriert werden.

Methode 1: ein Online-Scan

Am schnellsten geben Sie die Domain in den PQC-Status-Scanner ein. Er bietet dem Server jede standardisierte Post-Quanten-Gruppe einzeln an und meldet, welche akzeptiert werden, welche Gruppe ein moderner Browser tatsächlich erhält, die TLS-Versionen und Cipher Suites sowie die Zertifikatskette. Das dauert wenige Sekunden und erfordert keinen Zugriff auf den Server.

Methode 2: ein OpenSSL-Befehl

Bieten Sie mit OpenSSL 3.5 oder neuer (prüfbar mit openssl version) ausschließlich die hybride Gruppe an. Unterstützt der Server sie, gelingt der Handshake; andernfalls schlägt er fehl:

openssl s_client -connect example.com:443 -servername example.com \
  -groups X25519MLKEM768 -brief </dev/null

Ein Post-Quanten-bereiter Server antwortet mit Zeilen wie diesen:

Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

Ein Server, der nur klassische Gruppen unterstützt, beendet den Handshake mit einem Alert, typischerweise ssl/tls alert handshake failure (Alert-Nummer 40). Beachten Sie, dass s_client in beiden Fällen mit Status 0 endet: Werten Sie die Ausgabe aus, nicht den Exit-Code.

Um die anderen hybriden Gruppen zu testen, ersetzen Sie den Gruppennamen durch SecP256r1MLKEM768 oder SecP384r1MLKEM1024. Letztere ist die Option der Sicherheitsstufe 5, die die ANSSI nach Möglichkeit bevorzugt.

Methode 3: der Browser

Aktuelle Versionen von Chrome, Edge und Firefox bieten X25519MLKEM768 standardmäßig an. Öffnen Sie in Chromium-basierten Browsern die Entwicklertools, wechseln Sie zum Bereich Security (Sicherheit) und sehen Sie sich die Verbindungsdetails an: Die Zeile zur Schlüsseleinigung nennt die ausgehandelte Gruppe. Das zeigt, was Ihr eigener Browser erhalten hat. Für eine schnelle Prüfung ist das nützlich, hängt aber von der Browserversion ab.

Das Ergebnis richtig lesen

Ein CDN kann Ihren Ursprungsserver verdecken

Liegt Ihre Website hinter Cloudflare, Fastly, CloudFront oder einem anderen CDN, sieht jeder externe Test die Edge, nicht Ihren Server. Viele CDNs aktivieren die hybride Schlüsseleinigung an der Edge standardmäßig, sodass die Website bereit wirkt. Die Verbindung vom CDN zu Ihrem Ursprungsserver ist eine separate TLS-Verbindung, die möglicherweise noch ausschließlich klassische Schlüsseleinigung nutzt. Testen Sie den Ursprungsserver direkt mit dem obigen OpenSSL-Befehl, von einem Rechner aus, der ihn erreichen darf.

TLS 1.3 ist Voraussetzung

Hybride Schlüsseleinigung gibt es nur in TLS 1.3. Ein auf TLS 1.2 beschränkter Server kann nicht Post-Quanten-bereit sein, unabhängig von seinem Zertifikat. Das US-Memorandum OMB M-26-15 verlangt zudem TLS 1.3 für Bundessysteme bis Januar 2030.

Klassische Zertifikate sind heute normal

Ihr Zertifikat verwendet mit ziemlicher Sicherheit RSA oder ECDSA. Das ist zu erwarten: Öffentliche Zertifizierungsstellen stellen für das Web noch keine Post-Quanten-Zertifikate aus. Erfassen Sie den Zertifikatsalgorithmus in Ihrem Inventar, betrachten Sie ihn aber nicht als Hindernis für den Schritt der Schlüsseleinigung.

Alte Kyber-Entwürfe zählen nicht

Einige frühe Implementierungen nutzten X25519Kyber768Draft00, eine vorstandardisierte Version des Algorithmus. Sie ist veraltet: Server sollten auf die standardisierten ML-KEM-Gruppen umstellen.

Was tun, wenn die Antwort Nein lautet

1. Prüfen Sie die TLS-Bibliothek: OpenSSL 3.5 oder neuer oder eine gleichwertige Bibliothek mit ML-KEM-Unterstützung.
2. Aktivieren Sie die hybride Gruppe in Ihrem Webserver oder Load Balancer und behalten Sie X25519 als Fallback. Unser Leitfaden zur Aktivierung von ML-KEM in nginx, Apache, HAProxy und Caddy enthält die genauen Direktiven.
3. Wiederholen Sie den Test und tragen Sie das Ergebnis mit Datum in Ihr kryptografisches Inventar ein.