Zusammenfassung

  • Ein Transport-EOF belegt das Ende des Bytestroms, nicht die Vollständigkeit dessen, was der Peer senden wollte. close_notify fügt die geschützte Erklärung hinzu, dass in dieser Richtung keine weiteren TLS-Nachrichten kommen.
  • TLS 1.3 machte daraus einen gerichteten Abschluss statt eines sofortigen Endes beider Seiten. Ob eine HTTP-Nachricht vollständig ist, entscheiden weiterhin Länge, Chunk-Ende oder END_STREAM.

Ein unverfälschtes Stück kann unvollständig sein

Die letzte TLS-Aufzeichnung wird erfolgreich geprüft, danach meldet der Socket EOF. Das beweist die Integrität der empfangenen Folge. Es beweist nicht, dass die Folge so lang ist, wie ihr Absender sie vorgesehen hatte. Ein verlorener Schluss beschädigt die früheren Bytes nicht; er fehlt einfach im Beobachtungsraum des Empfängers.

Manche Anwendungsformate verraten die Lücke selbst. Eine angekündigte Content-Length wird nicht erreicht. Einer Chunk-Folge fehlt der abschließende Null-Chunk. Wird eine Antwort jedoch allein durch das Schließen der Verbindung begrenzt, sehen ein ordentlicher Schluss und ein abgeschnittener Rest von außen gleich aus.

TLS 1.0 formulierte das als Schutz vor Trunkierung. Mit close_notify sendet ein Peer innerhalb der geschützten TLS-Folge die Erklärung, dass er auf dieser Verbindung keine weiteren Nachrichten mehr senden wird. Datensätze nach dem Alarm sollen ignoriert werden.

Der Alarm erklärt nicht das Ende eines Dokuments oder Geschäftsprozesses. Seine Zuständigkeit reicht bis zum Ende der TLS-Nachrichten des Absenders. Ob deren Inhalt eine vollständige Antwort, Datei oder Transaktion bildet, kann nur die höhere Schicht erkennen.

Der frühe Standard belastete die nächste Verbindung

TLS 1.0 knüpfte an einen unsauberen Schluss eine zusätzliche Folge: Ohne korrekten Austausch der Abschlussalarme durfte die Sitzung nicht wiederaufgenommen werden. Wer das Ende nicht gemeinsam bestätigt hatte, verlor damit die Abkürzung zu einer späteren Verbindung.

Diese Kopplung überstand die Implementierungspraxis nicht. TLS 1.2 hält fest, dass bereits TLS 1.1 die automatische Nicht-Wiederaufnehmbarkeit entfernte, um verbreitetem Verhalten zu entsprechen. Die Pflicht zum Alarm blieb; sein Fehlen allein entwertete aber nicht mehr den Sitzungszustand.

So blieb die semantische Grenze bestehen, während eine nicht durchsetzbare Sanktion entfiel. Die Beweislage am Ende einer Verbindung und die Politik zur späteren Wiederaufnahme sind verwandt, müssen aber nicht dieselbe Entscheidung sein.

Der erzwungene Gegenschluss konnte Daten verwerfen

Vor TLS 1.3 musste der Empfänger eines close_notify umgehend den eigenen Alarm senden, die Verbindung schließen und ausstehende Schreibdaten verwerfen. Das machte den Abschluss symmetrisch, auch wenn die Anwendung noch asymmetrisch arbeitete.

Ein Client kann seine Anfrage beendet haben und weiterhin auf eine letzte Antwort warten. Verwirft der Server beim ersten Alarm die noch ausstehende Gegenrichtung, erzeugt der Mechanismus gegen Trunkierung selbst eine Trunkierung.

TLS 1.3 korrigierte dieses Modell. close_notify schließt geordnet eine Richtung: Der Absender beendet seine Schreibseite, nicht seine Leseseite. Der Empfänger muss weder sofort antworten noch ausstehende Daten der Gegenrichtung wegwerfen. Jede Richtung kann enden, wenn ihre Anwendung tatsächlich fertig ist.

Der Standard benennt auch die verbleibende Unsicherheit. Schließt der Transport vor dem Alarm, kann der Empfänger nicht wissen, ob alle vom Peer gesendeten Daten angekommen sind. Bereits authentifizierte Datensätze werden nicht nachträglich ungültig. Unbelegt bleibt nur, ob hinter dem letzten beobachteten Datensatz weitere vorgesehen waren.

HTTP liefert die Grenze, die TLS nicht kennt

Schon HTTP über TLS unterschied die Sicherheit empfangener Daten von der Vollständigkeit der Nachricht. Ein vorzeitiger Schluss bedeutet nicht, dass der empfangene Präfix unsicher ist, sondern dass spätere Daten fehlen könnten. TLS sieht die Grenzen von HTTP-Anfragen und -Antworten nicht; der Client muss deshalb die HTTP-Rahmung auswerten.

Die heutige HTTP/1.1-Spezifikation behält die Arbeitsteilung bei. Eine Content-Length ist erfüllt, wenn genau so viele Oktette eintreffen. Chunked Coding endet mit einem Null-Chunk. Fehlt die jeweilige Grenze, ist die Nachricht unvollständig. Eine nur durch Verbindungsschluss begrenzte Antwort darf über TLS erst nach einem gültigen Abschlussalarm als vollständig gelten.

HTTP/2 zeigt die Ebenen noch deutlicher. END_STREAM in RFC 9113 beendet eine Richtung eines einzelnen HTTP-Streams; andere Streams laufen auf derselben Verbindung weiter. Der Stream kann sein eigenes Ende belegen, lange bevor der gemeinsame TLS-Kanal geschlossen wird.

Ein Alarm trägt genau eine Aussage

close_notify authentifiziert keinen Menschen, genehmigt keine Transaktion, bestätigt keine Verarbeitung durch die Anwendung und zertifiziert nicht allein die Vollständigkeit einer höheren Nachricht. Es sagt: Von diesem Absender folgen in dieser Richtung keine weiteren TLS-Nachrichten.

EOF ist ein Ereignis des Transports. Der Alarm ist geschützter Beleg einer Sendeabsicht. Content-Length, Chunk-Ende und END_STREAM sind Belege der Anwendungsstruktur. Belastbare Systeme bewahren diese Unterschiede, statt alles in ein allgemeines „erfolgreich beendet“ zu pressen.

Quellen und Grenzen

Die Darstellung stützt sich auf RFC 2246, RFC 2818, RFC 5246, RFC 8446, RFC 9112 und RFC 9113. Sie belegen Regeln und historische Änderungen, nicht heutige Bibliotheksvorgaben, Verbreitungsanteile oder die Ursache eines fehlenden Alarms in einem konkreten Vorfall.