Netzwerkgeräte finden, die an einem Post-Quanten-Handshake scheitern

Eine Anwendung, die gegen OpenSSL 3.5 gebaut ist, sendet in ihrer ersten Handshake-Nachricht einen Post-Quanten-Schlüsselanteil, ohne dass jemand das eingestellt hätte. Die Standard-Gruppenliste der Bibliothek, so die Dokumentation, „selects X25519MLKEM768 as one of the predicted keyshares“, und dieselbe Seite nennt die mögliche Folge: „In rare cases this can lead to failures or timeouts because the resulting larger TLS Client Hello message may no longer fit in a single TCP segment and firewall software may erroneously disrupt the TLS handshake“ (OpenSSL, SSL_CTX_set1_groups_list). Ein gewöhnliches Bibliotheks-Upgrade kann deshalb dazu führen, dass eine Verbindung, die jahrelang funktioniert hat, in einen Timeout läuft, und die Ursache liegt in einem Gerät zwischen den beiden Enden. Dieser Beitrag beschreibt, wie sich solche Geräte im eigenen Netz vor dem Upgrade finden lassen.

Warum ein Post-Quanten-ClientHello in eine andere Größenklasse fällt

Ein klassisches ClientHello mit einem X25519-Schlüsselanteil umfasst einige hundert Byte. Der Schlüsselanteil für X25519MLKEM768 allein hat 1.216 Byte; die Größen für jeden Schlüsselaustausch stehen in Handshake-Bytes auf der Leitung. Ein TCP-Segment fasst auf einem gewöhnlichen Ethernet-Pfad 1.460 Byte, mit dem Rest der Nachricht kommt ein ClientHello, das den Schlüsselanteil trägt, also in zwei Segmenten an.

Das ist gültiges TLS, und es war früher selten. Cloudflare beschrieb die Folge, als es begann, Origin-Servern den Hybrid anzubieten: „it used to be so exceedingly rare to see a split ClientHello that there is plenty of software and hardware out there that falsely assumes it never happens“ (Cloudflare, „Cloudflare now uses post-quantum cryptography to talk to your origin server“, 29. September 2023). Derselbe Beitrag hält fest, wo der Fehler sitzen kann: „Rarely it’s just the server: there could be a load-balancer, and even a humble router could be at fault.“ tldr.fail dokumentiert die Serverseite des Fehlers. Für den Client sieht es in jedem Fall gleich aus: Die Verbindung bleibt ohne Antwort, oder sie wird zurückgesetzt.

Warum interne Netze dem Problem spät begegnen

Öffentliche Sites erhalten seit einiger Zeit hybride ClientHellos von Browsern, und die Pfade zu ihnen sind erprobt. Im Oktober 2026 handelten 186 von 351 antwortenden Hosts unter den 500 meistbesuchten Domains X25519MLKEM768 aus (Post-Quanten-Schlüsselaustausch auf den 500 meistbesuchten Domains, Oktober 2026). Der Verkehr innerhalb eines Unternehmens hat eine andere Vorgeschichte. Aufrufe zwischen Diensten und Appliances mit eingebettetem TLS-Stack haben bisher überwiegend kleine Hellos übertragen, sodass die Geräte dazwischen nie mit einem großen geprüft wurden.

Das erste große Hello kommt meist mit einem Upgrade, das auf den ersten Blick nichts mit Kryptografie zu tun hat. OpenSSL 3.5 ist eine Quelle. Go ist eine weitere: Seit Go 1.24 gilt für den Schlüsselaustausch X25519MLKEM768, er „is now supported and is enabled by default when Config.CurvePreferences is nil“ (Go, Go 1.24 Release Notes). Ein Dienst, der auf einer der beiden Grundlagen neu gebaut wird, sendet danach ein ClientHello über zwei Segmente, wo er zuvor einige hundert Byte sendete, und zwar an jeden internen Endpunkt, mit dem er spricht.

Ein Größentest, der den Pfad vom Server trennt

Die Frage an jeden internen Endpunkt lautet, wie groß ein ClientHello sein darf, das ihn erreicht und beantwortet wird. Der Test sendet zuerst ein kleines Kontroll-ClientHello und danach je ein ClientHello in jeder Client-Flight-Größe, die der Handshake-Größenrechner für einen Schlüsselaustausch bei seinem voreingestellten festen Anteil ausgibt. Es sind die Größen des Rechners, und das eigene ClientHello eines bestimmten Clients weicht durch seine übrigen Erweiterungen davon ab:

Jedes ClientHello trägt den Schlüsselanteil seiner Zeile und einen zweiten für X25519. Ein Server, der die Gruppe der Zeile nicht kennt, antwortet auf X25519. Das Ergebnis betrifft deshalb die Größe und gilt unabhängig davon, ob der Server Post-Quanten-Schlüsselaustausch unterstützt. Ein Hello, das länger ist als die Segmentgröße der Verbindung, wird als zwei Segmente mit einer Sekunde Pause dazwischen geschrieben, die Reproduktion, die tldr.fail verwendet.

Eine Größe gilt nur dann als fehlgeschlagen, wenn das Kontroll-Hello beantwortet wurde und das Hello dieser Größe zweimal ohne Antwort blieb, beim zweiten Mal vor einem Kontroll-Hello gesendet, das erneut beantwortet wurde. Die umgekehrte Reihenfolge verhindert, dass eine Ratenbegrenzung als Größengrenze gelesen wird. Alles darunter wird als unbekannt vermerkt. Das Ergebnis je Host ist das größte beantwortete ClientHello und die Größe, ab der die Antworten ausbleiben.

Ein Netz von innen scannen

pqprobe netcheck führt diesen Test von einem Rechner innerhalb des Netzes aus, gegen benannte Hosts oder ganze CIDR-Bereiche:

pqprobe netcheck 10.20.0.0/24 app.example.internal

Für jeden Host, der antwortet, meldet der Befehl den Größentest zusammen mit der Angabe, ob der Endpunkt Post-Quanten-Schlüsselaustausch anbietet. Beides gehört zusammen, weil sich die Abhilfe unterscheidet:

Die Zusammenfassung beginnt mit den Zählungen und führt die fehlschlagenden Hosts zuerst auf, gruppiert nach gemeinsamem Fehler: Hosts, die bei derselben Größe auf dieselbe Weise aufhören zu antworten. Die Gruppierung ist der nützliche Teil. Der Scan sieht Hosts, und ein Gerät wird nur als das sichtbar, was fehlschlagende Hosts gemeinsam haben. Zwanzig Hosts hinter einem Adressbereich, die alle bei 1.318 Byte aufhören, weisen auf das, was diesen Bereich bedient. Ein einzelner Host, der dort aufhört, während seine Nachbarn jede Größe beantworten, weist auf den Host selbst.

An einem öffentlichen Host ausprobieren

Der Rechner führt dieselben Größen in seinem Client-Flight auf und hat jetzt ein Host-Feld und eine Schaltfläche „Test“. Ein Klick darauf lässt unseren Server den Größentest gegen diesen Host ausführen und versieht jede Zeile mit ihrem Ergebnis. Die Seite stellt keine Netzwerkanfrage, bevor die Schaltfläche gedrückt wird. Der Test läuft unter denselben Grenzen wie die öffentliche Probe, einschließlich ihrer Opt-out-Liste.

Die Schaltfläche erreicht, was unsere Server erreichen. Sie prüft den Pfad aus dem Internet zu einem öffentlichen Host und gibt damit einen ersten Blick auf eine Edge-Firewall oder einen Load Balancer. Die Zeilen des Server-Flights bleiben ungeprüft, da ein Client den Server eines anderen nicht dazu bringen kann, eine andere Zertifikatskette zu senden. Hosts in einem internen Netz und die Pfade, die die eigenen Clients zu ihnen nehmen, brauchen den Kommandozeilen-Scan von innen.

Was mit einem fehlschlagenden Host zu tun ist

Die dauerhafte Abhilfe liegt in dem Gerät, an dem das Hello scheitert: ein Firmware-Update oder eine geänderte Konfiguration einer Inspektionsfunktion, die den Handshake auswertet. Bis dahin dokumentiert OpenSSL auf der oben zitierten Seite eine Übergangslösung auf der Client-Seite, eine Gruppenliste mit dem Präfix ?X25519MLKEM768:, die den Hybrid im Angebot hält und seinen Schlüsselanteil aus dem ersten ClientHello herauslässt. Der Client erreicht den Hybrid dann nur, wenn der Server ihn in einem zweiten Roundtrip anfordert, und der Scan meldet für jeden Host, ob der Server das tut. Wo er es unterlässt, verbindet die Übergangslösung ohne Fehlermeldung über klassischen Schlüsselaustausch. Ein solcher Host braucht deshalb weiterhin einen instand gesetzten Pfad, bevor seine Sitzungen post-quantensicher sind.