Zusammenfassung

  • Vier TLS-Leitlinien ergaben rund 14 bis 80 Prozent Nichtkonformität, als sie auf dieselben 50,7 Millionen Server-Hello-Nachrichten aus einer Institution über 14 Tage angewandt wurden.
  • Die Stichprobe enthält 6,85 Millionen Handshakes mit X25519MLKEM768, einer hybriden Post-Quanten-Gruppe, die in keiner der vier untersuchten Leitlinien erwähnt wird. „Nicht aufgeführt“ heißt nicht „gebrochen“.
  • TLSGatekeeper kann ausgewählte Handshake-Werte beobachten und Verbindungen optional sperren, ohne Anwendungsdaten zu entschlüsseln. Der 100-Gbit/s-Wert stammt aus einem Laboraufbau ohne aktive Sperre, nicht aus einem berichteten Produktionseinsatz.

Dieselbe Verbindung, ein anderes Regelwerk

Die Kennzahl „80 Prozent nicht konform“ wirkt in einem Sicherheits-Dashboard wie eine Eigenschaft des Netzes. In dieser Studie ist sie zugleich eine Eigenschaft des Regelwerks, mit dem der Verkehr bewertet wurde.

Ein Gastbeitrag im APNIC Blog stellt die Untersuchung von Henrique Becker Brum und Kolleginnen und Kollegen der Universität Trient und der Fondazione Bruno Kessler vor. Die Arbeit, veröffentlicht als arXiv:2605.31020v1, vergleicht zwei Wochen Datenverkehr mit vier nationalen Cybersicherheitsleitlinien: ACN aus Italien, ANSSI aus Frankreich, BSI aus Deutschland und NIST aus den USA. Bei den drei untersuchten Feldern reichte die Nichtkonformität von etwa 14 Prozent nach ANSSI bis 80 Prozent nach NIST.

Der Handshake ändert sich nicht, wenn das Regelwerk wechselt. Das Etikett ändert sich. Macht eine Organisation aus diesem Etikett eine automatische Sperre, bestimmt die Auslegung eines Dokuments, welche Verbindungen ihre Nutzer aufbauen können.

Die Leitlinien sind weder nutzlos noch zwingend willkürlich. Sie gelten für unterschiedliche Behördenumgebungen, Bedrohungsmodelle und Migrationspfade. Problematisch wird es, wenn ein System drei Zustände zusammenwirft: eine bekannte Schwachstelle, ein ausdrückliches Verbot und einen Wert, der noch nicht bewertet wurde. Alles als „nicht konform“ zu markieren, vereinfacht die Automatisierung, aber erschwert die Erklärung.

Was die Messung umfasst

Die Erhebung lief vom 13. bis 26. Oktober 2025 im Datenverkehr aus dem internen Netz der Fondazione Bruno Kessler zu externen Servern. Nach der Bereinigung zählten die Forschenden 155.066.707 Pakete. 50.744.009 Server-Hello-Nachrichten bildeten die Grundlage für die Auswertung der vom Server gewählten TLS-Version, Cipher-Suite und unterstützten Gruppe.

Diese Größenordnung zeigt Muster innerhalb der Institution. Sie macht aus einer Institution keine globale Erhebung. Handshake-Zahlen sind keine Zahl eindeutiger Nutzer, Server oder Organisationen. Arbeitsplätze, interne Dienste, Besucher, Fernzugriff und Arbeitszeiten prägen die Stichprobe. Die Autoren beschreiben das Netz als vielfältig; das ersetzt keine geografische oder branchenübergreifende Stichprobe.

Analysiert werden drei vom Server gewählte Werte, und zwar nacheinander: Version, Cipher-Suite, Gruppe. Scheitert das erste Feld an der ausgewählten Leitlinie, werden spätere Felder nicht als Grund für denselben Nichtkonformitätsfall gezählt. Die Studie prüft weder jede Serverkonfiguration noch Zertifikate, Software, Einsatzumgebung oder das Verhalten nach dem Handshake. „Konformität“ bezeichnet hier den Vergleich ausgewählter Werte mit bestimmten Regeln, keine umfassende Sicherheitszertifizierung eines Endpunkts.

Diese Begrenzung reicht bereits aus, um ein Betriebsproblem zu zeigen: Die vier Dokumente teilen kein universelles Vokabular akzeptabler Werte.

„Nicht aufgeführt“ ist ein eigener Zustand

Das deutlichste Beispiel ist X25519MLKEM768. Der Datensatz enthält 6.845.778 Server-Hello-Nachrichten, in denen der Server diese Gruppe wählte – rund 13,5 Prozent der Stichprobe. In der Tabelle der nicht konformen Werte erscheint sie, obwohl sie in keiner der vier untersuchten Leitlinien genannt wird.

Der Name verbindet X25519, eine weit verbreitete klassische Gruppe, mit ML-KEM, dem vom NIST in FIPS 203 standardisierten Post-Quanten-Kapselungsmechanismus. Daraus folgt nicht, dass jeder einzelne Handshake „quantenfest“ ist. Die Messung belegt eine Serverauswahl in dieser Stichprobe, nicht die Sicherheit der gesamten Sitzung, die Implementierung auf der Client-Seite oder eine Ende-zu-Ende-Migration. Ebenso darf der Wert nicht mit X25519Kyber768_Draft00 verwechselt werden, einem älteren Entwurfswert, den die Arbeit gesondert behandelt.

Die betriebliche Folgerung ist präzise: Eine nicht aktualisierte Positivliste kann einen real verwendeten Wert als nicht konform markieren, obwohl die Forschenden dafür keine bekannte Schwachstelle anführen. Die Leitlinie ist auf etwas außerhalb ihres Vokabulars gestoßen. Das ist ein Grund, die Regel zu überprüfen – kein Beweis, dass der Wert gesperrt werden sollte.

Auch die Gegenrichtung ist relevant. Laut Studie ist Curve25519 weit verbreitet und wird von großen Browsern akzeptiert, ist aber in der untersuchten NIST-Leitlinie nicht zugelassen. ChaCha20-Poly1305 ist modern, wird von NIST jedoch missbilligt. Das ist kein Aufruf, öffentliche Anforderungen zu ignorieren. Es zeigt, dass „entspricht dieser Basis nicht“ und „ist kryptografisch gebrochen“ unterschiedliche Aussagen mit unterschiedlichen Belegen und Folgen sind.

Ein binärer Status reicht nicht. Betreiber sollten mindestens unterscheiden: durch eine benannte, datierte Richtlinie ausdrücklich verboten; erlaubt; nicht bewertet oder noch nicht aufgeführt; sowie auf technischer Grundlage als verwundbar bekannt. Aus dem Fehlen in einer Liste darf keine Verwundbarkeit abgeleitet werden. Eine Richtlinie kann einen Wert aus Gründen ihres Geltungsbereichs ausschließen, ohne einen Bruch zu behaupten. Das Protokoll muss diesen Grund festhalten.

Vom Beobachten zum Sperren

TLSGatekeeper ist ein XDP/eBPF-basierter Netzwerk-Middlebox-Prototyp. Er liest ausgewählte Felder aus Server-Hello- oder Server-Key-Exchange-Nachrichten, vergleicht sie mit einer Richtlinie, protokolliert das Ergebnis und kann die Verbindung optional sperren. Anwendungsinhalte entschlüsselt er nicht. Da er vom Server gewählte Werte prüft, verbirgt Encrypted Client Hello zwar das clientseitige SNI, nicht aber die untersuchten Server-Felder.

Damit wandert der Kontrollpunkt von einzelnen Browsern oder Anwendungen an den Netzausgang. Eine Organisation kann eine Regel auf viele Clients anwenden, ohne jedes Gerät einzeln zu konfigurieren. Das kann bei temporären oder nicht direkt verwalteten Geräten helfen. Zugleich entsteht ein gemeinsamer Fehlerpunkt: Eine falsche Regel, eine Parsergrenze oder ein ungeprüftes Update kann alle Nutzer treffen, deren Verkehr diesen Punkt durchläuft.

Die Leistungsbewertung nutzte zwei BlueField-2-DPUs an einer 100-Gbit/s-Verbindung innerhalb eines Servers. Mit 16 Hintergrundströmen näherte sich die Verbindung der Leistungsgrenze der Hardware. Die Autoren berichten eine mittlere Prüfverzögerung von 671 Nanosekunden für TLS-1.3- und 795 Nanosekunden für TLS-1.2-Handshake-Pakete.

Das sind Labormessungen der Paketverarbeitung, keine Zusage für Leitungsgeschwindigkeit in jeder Architektur oder Verkehrsmischung. Entscheidend ist außerdem: Im Leistungstest war die Sperre deaktiviert. Die Pakete gelangten mit XDP_PASS in den Netzwerk-Stack des Hosts. Der Test zeigt geringe gemessene Prüfkosten in diesem Aufbau. Er belegt weder die Zuverlässigkeit aktiver Sperren im Produktionsbetrieb noch die Richtigkeit einer bestimmten Richtlinie oder existierende Produktivkunden.

Auch die Implementierung hat eine klare Grenze: klassisches TLS über TCP, nicht QUIC oder DTLS. Betreiber müssen wissen, welcher Verkehr die Prüfung umgeht. „Keine Entschlüsselung“ ist ein relevanter Datenschutzvorteil, bedeutet aber keine Machtlosigkeit: Die Middlebox kann ein Handshake-Paket durch einen TLS-Alert ersetzen und so den Verbindungsaufbau verhindern.

APNIC als Forum, nicht als Betreiber der Messung

Der APNIC Blog bietet eine öffentliche technische Plattform für die Region Asien-Pazifik. Ein Gastbeitrag belegt nicht, dass APNIC TLSGatekeeper entwickelt, getestet oder betrieben hat. Autorenaffiliationen und Gastbeitrags-Hinweis grenzen die Forschung vom Registry-Betrieb ab.

Für regionale Betreiber lautet die sinnvolle Frage nicht, welches Land „gewinnt“. Entscheidend ist, wie eine lokale Regel zur Netzentscheidung wird. Eine Behörde kann für einen bestimmten öffentlichen Dienst ein Profil vorschreiben. Eine Universität kann für verwaltete Geräte eine andere Basis wählen. Ein Netzteam kann einen neuen Schlüsselaustausch zulassen müssen, während es die Sicherheitsprüfung abschließt. Diese Entscheidungen können nebeneinander bestehen, wenn Geltungsbereich, zuständige Stelle, Protokoll und Dokumentversion erfasst werden.

Eine Liste ohne Kontext lässt sich schlecht übertragen. Ein Wert kann in einem Profil zulässig und in einem anderen verboten sein. Nach einem Leitlinien-Update kann eine unveränderte Verbindung plötzlich als nicht konform gelten. Steht im Protokoll nur „gesperrt: nicht konform“, lässt sich womöglich nicht mehr feststellen, welche Regel wirkte oder ob es ein Verbot, eine fehlende Bewertung oder bloß eine fehlende Nennung war.

Eine nachvollziehbare Entscheidung sollte das geprüfte Feld, den beobachteten Wert, Kennung und Ausgabe der Leitlinie, den Ablehnungsgrund, den Zeitpunkt und den Weg zu Ausnahme oder Korrektur bewahren. Sonst ist die Ausführung deterministisch, die Governance aber undurchsichtig.

Eine sicherere Übersetzung von Leitlinie zu Paket

Ein vertretbarer Ansatz kodiert drei Zustände: erlaubt, verboten und nicht bewertet. Bekannte Schwachstellen bekommen eine getrennte technische Begründung. „Nicht bewertet“ sollte sichtbar werden und eine Prüfung auslösen, statt stillschweigend das Verhalten von „verboten“ zu übernehmen.

Wenn Sperren vorgeschrieben sind, kann eine neue Regel zuerst im Beobachtungsmodus laufen. Betreiber messen die betroffenen Verbindungen, identifizieren Dienste, testen die Änderung in einem begrenzten Segment und weiten sie erst danach aus. Die Regel sollte Quelle, Datum, Verantwortlichen und Prüftermin enthalten. Ausnahmen brauchen Genehmiger und Ablaufdatum; der Rückweg sollte vor der breiten Durchsetzung getestet werden.

Das sind redaktionelle Empfehlungen, keine Funktionen, die das Paper TLSGatekeeper zuschreibt. Sie folgen aus der Lücke zwischen Dokumentvergleich und Paketaktion. Policy-Autoren bestimmen den Wortlaut, Netzbetreiber die lokale Übernahme, Maintainer das Parserverhalten, Nutzer tragen die Folgen gescheiterter Verbindungen. Ein Entscheidungsbeleg sollte diese Zuständigkeiten bewahren, statt die Middlebox als Quelle einer universellen Wahrheit namens Konformität erscheinen zu lassen.

Heng Lus Note 64 liefert eine hilfreiche Gestaltungsperspektive: Eine gemeinsame technische Basis sollte nicht jede künftige Wahl in eine zentrale Genehmigungsfrage verwandeln. Das heißt nicht, öffentliche Vorgaben zu ignorieren. Es heißt, ihren Geltungsbereich genau zu bestimmen und die Folgen lokal zu prüfen. Besonders wichtig ist das, wenn der auffälligste „Fehler“ eine kryptografische Option ist, der die Richtlinie noch nicht gefolgt ist.

Was die Belege aussagen – und was nicht

Die Forschenden zeigen, dass eine große institutionelle Stichprobe neue und alte TLS-Werte enthält, dass Leitlinien zu unterschiedlichen Ergebnissen kommen und dass eine Middlebox ausgewählte Felder in einem Labor mit hohem gemessenem Durchsatz prüfen konnte. Sie zeigen nicht, wie häufig Organisationen diese Werte in Produktion sperren, welche Nutzerschäden entstehen, wie repräsentativ die Stichprobe ist oder was die hybride Gruppe für Ende-zu-Ende-Sicherheit bedeutet.

Diese Lücken entwerten die Untersuchung nicht. Sie trennen eine nützliche Messung von einer unbelegten Einsatzbehauptung. Der stärkste Befund lautet nicht „80 Prozent von TLS sind unsicher“. Er lautet: Derselbe beobachtete Verkehr kann unter vier maßgeblichen Regelwerken sehr unterschiedlich bewertet werden, und Betreiber können diese Differenz in eine Netzentscheidung übersetzen.

Wenn die Leitlinie „nicht aufgeführt“ sagt, sollte der Paketprozessor die fehlende Begründung nicht erfinden. Jemand muss entscheiden, ob der Wert verboten, nicht bewertet oder durch eine neuere lokale Vorgabe erlaubt ist. Diese Entscheidung muss sichtbar, überprüfbar und rückgängig zu machen sein. Sonst wird die Zulassungsliste unbemerkt selbst zur Sicherheitsrichtlinie, statt lediglich eine umzusetzen.

Quellen