Zusammenfassung

  • TLS 1.3 schützt Inhalt, ein internes Typ-Oktett und nachfolgende Nullbytes gemeinsam. Der Sender wählt das Padding; der Empfänger prüft und entfernt es vor der Übergabe. Zusätzliche Darstellung ist keine zusätzliche Anwendungsbedeutung.
  • Ein Mitschnitt belegt Ciphertext-Länge, Richtung und Zeit. Inhalt, Typ, Padding und AEAD-Aufwand kann er nicht direkt trennen. Ein größerer Record beweist daher keine größere Anwendungsnachricht.
  • Padding kann Größenfingerabdrücke vergröbern und Deckverkehr erzeugen. Timing, Anzahl, Antworten, Fragmentierung und Verarbeitung bleiben mögliche Signale. Belastbare Aussagen benötigen Endpoint-Werte, eine versionierte Policy, Limits und Ablehnungsbelege.

Eine richtige Zahl erzählte das falsche Ereignis

Zwei ausgehende Records derselben Verbindung unterschieden sich um 512 Bytes. Der größere lag zeitlich neben einer sensiblen Operation. Der Unterschied wurde als Request-Body und anschließend als Nutzerhandlung beschrieben.

Im Endpoint-Protokoll stand die fehlende Tatsache: Ein Callback ergänzte Nullbytes bis zur nächsten Blockgrenze. In Leerlaufphasen konnte ein anderer Baustein Application Data mit leerem Inhalt erzeugen. Die Bytes verbrauchten Bandbreite, waren aber nicht vollständig Nutzdaten.

Nicht der Sensor versagte. Netzbelegen wurde die Befugnis gegeben, Semantik hinter einer unsichtbaren Grenze festzulegen.

Die Grenze in TLSInnerPlaintext

TLSInnerPlaintext besteht aus Inhalt, einem Nichtnull-ContentType und abschließenden Nullbytes. Die gesamte Struktur wird geschützt. Der äußere Typ sieht wie Application Data aus und verrät den inneren Typ nicht.

Nach erfolgreicher AEAD-Prüfung durchsucht der Empfänger ausschließlich den zurückgegebenen Klartext von hinten. Nullbytes sind Padding; das erste Nichtnull-Oktett ist der Typ; davor liegt der Inhalt. Fehlt ein Nichtnullwert, beendet er die Verbindung mit unexpected_message.

Erst dort ist die Trennung autoritativ. Die Anwendung erhält den Inhalt ohne Padding. Authentisierte Nullen werden weder Befehl noch Identität, Credential oder Berechtigung.

Deckverkehr folgt einer engen Grammatik

Application Data darf leeren inneren Inhalt tragen. Ein Sender kann während echter Stille einen plausibel großen geschützten Record erzeugen. Sichtbarer Verkehr belegt dann nicht automatisch Anwendungsaktivität.

Handshake und Alert dürfen nicht auf diese Weise leer sein. Padding macht aus einem leeren Körper keine gültige Protokollnachricht; der Empfänger muss ablehnen.

Deckverkehr garantiert auch keine Ununterscheidbarkeit. Antwort, Verarbeitungsdauer, Burst oder Verbindungsende können echte Arbeit verraten. Padding schwächt ein Signal, nicht alle.

Nullbytes zählen gegen das Limit

In das Maximum gehen Inhalt, Typ und Padding ein. Ein empfangenes record_size_limit begrenzt den vollständigen TLSInnerPlaintext.

Eine Policy, die 1.024 Bytes anfordert, bestimmt deshalb nicht stets das Ergebnis. Inhalt belegt Raum; die Implementierung kann kürzen oder anders fragmentieren. OpenSSL begrenzt die Zugabe auf den verbleibenden Höchstwert.

Dieselbe Nachricht kann einen oder mehrere Records bilden oder die gewünschte Klasse verfehlen. Ohne Limit, Fragmentierung und tatsächlich angewandte Länge lässt sich der Pfad nicht aus dem Ciphertext rekonstruieren.

Vorhandene Funktion ist keine aktive Policy

Die aktuelle TLS-1.3-Spezifikation definiert Mechanismus und Prüfung, aber keine universelle Blockgröße oder Deckfrequenz. Anwendungen können ihre sensiblen Grenzen besser kennen; verschlüsselte Handshake- und Alert-Nachrichten bleiben Aufgabe der TLS-Schicht.

OpenSSL nutzt standardmäßig kein Record-Padding. Es bietet Blockgrößen und einen Callback vor der Verschlüsselung jedes geschriebenen Records, getrennt für Application Data und Handshake/Alert. Ein Callback kann kernel TLS ausschließen.

GnuTLS bietet Padding pro Sendung und eine Abfrage zur Längenverschleierung. API und IANA-Eintrag beweisen Verfügbarkeit, nicht Aktivierung, angewandte Länge oder Privatsphäregewinn.

Konstante Bibliothekszeit genügt nicht

Das Entfernen von Padding kann längenabhängige Laufzeit zeigen. GNUTLS_SAFE_PADDING_CHECK mindert dieses Signal gegen Leistungskosten.

Danach verarbeitet die Anwendung den echten Inhalt. Parsing, Speicher, Datenbank und Antwort können datenabhängig bleiben, selbst wenn die Bibliothek konstant arbeitet.

TLS verspricht deshalb keine vollständige Traffic-Analysis-Abwehr. Stärkere Garantien verlangen Kooperation höherer Schichten, mehr Volumen und oft Verzögerung. „Padding aktiv“ ist ein Funktionszustand, kein abschließendes Datenschutzniveau.

Die Protokollkombination entscheidet über die Schicht

EAP-TLS 1.3 empfiehlt Record-Padding gegen Zertifikatsgrößenlecks. ECH rundet den inneren ClientHello separat und nennt spätere verschlüsselte Handshake-Felder, die TLS-Padding benötigen können. Das Schutzziel steht jeweils zuerst.

HTTP/3 unterscheidet Anwendungs-, reservierte und Transportmechanismen. QUIC nutzt TLS-Handshake-Nachrichten, transportiert aber keine gewöhnlichen TLS-Records. Ein TLS-Callback belegt kein QUIC-Paket-Padding.

Integrity-only-Suites liefern die Gegenprobe: Padding kann integer geschützt sein, verschleiert ohne Verschlüsselung aber keine Klartextlänge. Nullen allein schaffen keine Vertraulichkeit.

Was ein Beobachter sagen darf

Ein passiver Mitschnitt belegt Endpunkte, Richtung, Zeit, Ciphertext-Länge, Pakete und Wiederholung. Inneren Typ, Inhalt, Padding und Bedeutung sieht er nicht direkt.

Die begrenzte Aussage lautet: „Endpoint E sendete bei T einen geschützten Record von N Oktetten.“ Endpoint-Belege ergänzen: „C Inhalt, Policy P Version V, Z Padding, innere Länge I und Ciphertext N unter Limit L.“

Ohne diese Verbindung stützt eine Verteilung eine Hypothese, aber keine Nutzerhandlung, Objektgröße oder Anweisung.

Ein beweisfähiges Betriebsprotokoll

Speichern: Verbindung, Richtung, Sequenz, TLS-Version, Schutzmodus, inneren Typ, Inhalt vor Padding, angeforderte und angewandte Zugabe, innere und verschlüsselte Länge, Limit, Fragmentierung, Bibliotheksversion, kernel TLS und Policy-Version.

Messen: Bandbreite, Latenz, CPU, Größenklassen, Antwortkorrelation und Deckanteil. Application Data und Handshake/Alert getrennt behandeln.

Negativ testen: ausschließlich nuller Klartext, leere Handshake/Alert, übergroße Anforderung und Limitüberschreitung. Nach Rollback das Verschwinden von Callback-Aktivität und Längenverteilung beweisen.

Das entscheidende Feld bleibt im Netz unsichtbar: Inhalt vor Padding. Ohne es ist sichtbare Länge Netzbeleg, nicht Anwendungsautorität.

Quellen