Zusammenfassung

  • close_notify ist in TLS 1.3 eine authentisierte Aussage für eine Richtung: Der Absender wird auf dieser Verbindung keine weiteren TLS-Nachrichten senden. Die Gegenrichtung bleibt eigenständig; Request, Response, Stream oder dauerhafte Wirkung werden nicht quittiert.
  • Ein Transport-EOF ohne den Alert lässt eine Kürzung möglich. Als kompatibler Abschluss ist er nur vertretbar, wenn das Anwendungsprotokoll Vollständigkeit unabhängig erkennt und die Anwendung diese Prüfung tatsächlich durchführt.
  • Autorität für Wiederholung und Zuschreibung braucht vier getrennte Grenzen: Anwendungsnachricht, lokaler und entfernter TLS-Abschluss, Transportende und dauerhaftes Ergebnis. Ein einziges Feld closed vernichtet diese Reihenfolge.

Ein erfolgreicher Shutdown ohne erfolgreichen Vorgang

Der Server baute die positive Antwort vor dem endgültigen Commit. Er schrieb die TLS-Records, versandte close_notify und protokollierte shutdown=success. Wenige Millisekunden später wies die Datenbank die Änderung wegen eines Eindeutigkeitskonflikts zurück.

Der Client hatte kein gefälschtes Ende gesehen. Die ausgewählten Daten lagen geordnet vor dem authentisierten Alert. Was fehlte, war eine Commit-ID der zuständigen Anwendung. Ein TLS-Ende kann die Existenz einer Antwort belegen, nicht deren Wahrheit über ein anderes System.

Die operative Fehlannahme gab dem letzten Netzwerkereignis Geschäftsautorität. TLS schützt und ordnet Bytes; es sieht weder Datenbanktransaktionen noch Warteschlangen oder nachgelagerte Entscheidungen.

Zwei Richtungen enden getrennt

Mit close_notify verspricht ein Absender, keine weiteren TLS-Nachrichten zu senden. Daten nach diesem Alert sind zu ignorieren. Seine Leseseite darf offenbleiben, denn der Peer kann noch eigene Daten übertragen, bevor er seine Richtung beendet.

Jede Seite muss den Alert vor dem Schließen ihrer Schreibseite senden, sofern sie nicht bereits einen Fehler-Alert verschickt hat. TLS 1.3 verlangt keine sofortige Antwort mehr, die ausstehende Schreibdaten verwerfen könnte. Ordnungsgemäßer Abschluss ist deshalb kein atomarer Zustand der ganzen Verbindung.

Auch TCP kennt Half-Close. Ein FIN beendet jedoch einen geordneten Bytestrom und ist kein authentisierter TLS-Alert. Es benennt weder den letzten vollständigen TLS-Record noch eine Anwendungsgrenze.

EOF ist die schwächere Aussage

Verschwindet der Transport vor close_notify, kann der Empfänger nicht wissen, ob alle beabsichtigten Daten ankamen. Prozessabsturz, Proxy-Timeout, nicht konformer Peer und absichtliche Kürzung können gleich aussehen. Das fehlende Signal beweist keinen Angriff, sondern bewahrt Ungewissheit.

Fataler Alert, RST, Timeout, unerwartetes EOF, empfangener Abschluss-Alert und lokaler Sendeversuch müssen unterschiedliche Befunde bleiben. Das Sammelwort „disconnected“ löscht Richtung und Reihenfolge.

IANA ordnet close_notify den Alert-Wert 0 zu. Das Register belegt Codepoint und Referenz, nicht den Produktionspfad oder die Vollständigkeit der vorherigen Nachricht.

Die Anwendung bestimmt ihre Nachrichtengrenze

TLS behandelt geschützte Inhalte als opak. Records vor dem Alert sind geordnet und authentisiert, doch TLS erkennt darin weder vollständiges Dokument, letzten Chunk, Quittung noch Commit-Beleg.

Das höhere Protokoll braucht einen eigenen Abschluss: deklarierte Länge, Trennzeichen, terminaler Chunk, Stream-FIN, endgültiger Status, Request-ID, Bestätigung oder dauerhafter Ledger-Eintrag. Vollständige Nachricht und erfolgreicher Vorgang sind weitere getrennte Tatsachen.

Puffer schaffen zusätzliche Zwischenstände. Eine erfolgreiche Schreiboperation kann Bytes nur in TLS oder BIO abgelegt haben. Bei nicht blockierender E/A kann ein Alert-Versuch protokolliert werden, bevor er den Transport erreicht. Keiner dieser Punkte belegt externe Dauerhaftigkeit.

OpenSSL liefert Zustände, kein Ja oder Nein

Ein Rückgabewert 0 von SSL_shutdown() bedeutet normalerweise: lokales close_notify gesendet, Peer-Alert noch offen. Das ist kein Fehler und kein beidseitiger Abschluss. Erst 1 steht für gesendete und empfangene Alerts beider Seiten.

Der erste Aufruf schließt TLS-Schreiben, lässt Lesen möglich und hält TCP offen. OpenSSL empfiehlt weiterzulesen, damit letzte Anwendungsdaten und Post-Handshake-Nachrichten verarbeitet werden. Ein zweiter Shutdown ohne das Leeren anstehender Daten kann scheitern.

Das sent-Flag folgt dem Sendeversuch, received dem Peer-Alert. Quiet Shutdown setzt lokalen Zustand ohne Alert und ist nicht protokollkonform. Seit OpenSSL 3.0 ist unerwartetes EOF ein eigener TLS-Fehler. SSL_OP_IGNORE_UNEXPECTED_EOF ist nur zulässig, wenn das Anwendungsprotokoll Kürzung eindeutig erkennt und die Prüfung ausgeführt wird.

GnuTLS trennt GNUTLS_SHUT_WR und GNUTLS_SHUT_RDWR; BoringSSL führt Lese- und Schreibzustand separat. Die Bibliotheken stellen die Unterscheidung bereit. Telemetrie muss sie erhalten.

HTTP besitzt die fehlende Vollständigkeitsregel

Bei HTTP/1.1 verlangt Content-Length genau die angekündigten Oktette. Chunked Encoding verlangt den terminalen Null-Chunk. Fehlt eines, macht ein Verbindungsschluss die Antwort nicht vollständig.

Nur durch Schließen begrenzte Antworten sind heikler. Ihre Nachrichtengrenze hängt von einem gültigen Verbindungsende ab; ein unvollständiger TLS-Abschluss lässt sie unvollständig. RFC 9112 empfiehlt explizite Längen oder Codierungen, weil ein Netzfehler wie ein normales Ende aussehen kann.

Wurde eine Länge oder der End-Chunk bereits geprüft, bleibt diese Anwendungsgrenze trotz später fehlendem Peer-Alert erhalten. Genau dieser Nachweis ist nötig, um EOF aus Kompatibilitätsgründen zu akzeptieren: jede verwendete Nachricht braucht eine unabhängig verifizierte Grenze.

Multiplexing verlangt eine Request-Grenze

HTTP/2 führt viele Streams über eine TLS-Verbindung. close_notify sagt nicht, welche Requests der Server zu bearbeiten begann. GOAWAY liefert eine letzte Stream-ID und grenzt die möglicherweise verarbeiteten Streams ein.

Ohne GOAWAY bleibt ein nicht idempotenter POST in Bewegung unklar. HTTP/3 nutzt über QUIC dieselbe Anwendungsidee und begrenzt mit GOAWAY angenommene Requests. Ein Verbindungsschluss erzeugt keine Quittung pro Anfrage.

Alles erneut zu senden kann Zahlungen doppeln; nichts erneut zu senden kann Arbeit verlieren. Methodenbedeutung, Idempotenzschlüssel, Ergebnisabfrage und Abstimmung schaffen Wiederholungsautorität.

QUIC hat einen anderen Schlussmechanismus

QUIC verwendet TLS für den Handshake, schützt Anwendungsdaten aber nicht mit TLS-Records. TLS-Alerts werden zu QUIC-Verbindungsfehlern; QUIC definiert CONNECTION_CLOSE, Stream-FIN, Reset, Closing und Draining. Die Warning-Semantik von close_notify ist nicht übertragbar.

HTTP/3 braucht zusätzlich GOAWAY, weil auch QUIC-Abschluss nicht allein benennt, welche Requests angenommen wurden. Metriken müssen den Träger nennen: TLS-Alert, TCP FIN oder RST, QUIC Stream-FIN, CONNECTION_CLOSE, Idle Timeout, HTTP GOAWAY oder Anwendungsquittung.

Ein beweisfähiges Ende erfassen

Endpunktrolle, Richtung, TLS-Version, Korrelationswert und letzte vollständige Nachricht oder Stream erfassen. Framing-Regel, erwartete und empfangene Bytes, Request-ID, Idempotenzschlüssel und Wiederholungsklasse aufbewahren.

Für TLS lokale Alert-Warteschlange und Versand, empfangenen Peer-Alert, Rückgabesequenz, Lese- und Schreibflags, anstehende Daten und genaue Fehlerklasse trennen. Quiet Mode, EOF-Regel, Bibliotheksversion, kTLS und Proxy-Grenze gehören dazu.

Im Transport FIN, RST, EOF, Timeout und Half-Close unterscheiden. Bei Multiplexing GOAWAY-Grenze und Stream-Ende erhalten. Im Geschäftssystem Quittung, Commit-ID, dauerhaften Zeitpunkt und ausstellende Autorität speichern.

Negative Tests sollen TCP vor dem Alert trennen, den End-Chunk entfernen, nach vollständigem Frame aber vor Commit schließen, Rückgabewert 0 erfassen, Peer-Daten ungelesen lassen, Quiet Shutdown und EOF-Regeln wechseln sowie HTTP/2 oder HTTP/3 mit nicht idempotentem Request beenden.

Quellen