Zusammenfassung

  • Nach RFC 9846 schließt close_notify eine TLS-Senderichtung geordnet ab und liefert dem Empfänger eine kryptografische Grenze gegen unbemerkte Verkürzung. Die Meldung bestätigt weder Verarbeitung noch dauerhafte Speicherung, Wirkung oder Abrechnung in der Anwendung.
  • Ein belastbarer Abschlussbeleg verbindet den letzten angenommenen TLS-Record und den Alert mit einer getrennten Transaktionskennung, einem autoritativen Ergebnis und einer Wiederholungsregel. Zeitliche Nähe darf die beiden Beweise nicht ineinander verwandeln.

Ein Zahlungsprogramm sendet eine Anweisung, leert seinen Puffer und empfängt anschließend close_notify vom Server. Die TLS-Bibliothek meldet ein fehlerfreies Datenende. Wenn das Programm nun „bezahlt“ speichert, worauf stützt es sich? Nicht auf den Alert. Der Server könnte die Bytes gelesen und den Auftrag abgelehnt haben. Er könnte ihn geparst haben und vor dem Commit ausgefallen sein. Oder der Commit war erfolgreich, während allein die Antwort verlorenging. Der Transport kann diese Fälle nicht unterscheiden.

RFC 9846, der Proposed Standard für TLS 1.3 vom Juli 2026, löst RFC 8446 ab, behält die Protokollversion aber bei und ergänzt kompatible Klarstellungen. close_notify erhält darin eine eng umrissene Aufgabe: den geordneten Abschluss einer Richtung der Verbindung anzuzeigen. Der Sender erklärt, dass er auf dieser Verbindung keine weiteren TLS-Nachrichten senden wird. Nach Empfang sind spätere Daten zu ignorieren; die TLS-Implementierung soll der Anwendung das Datenende anzeigen.

Das Wort „Richtung“ trägt den wesentlichen Betriebsinhalt. Jede Seite kann mit close_notify ihre Schreibseite schließen, ohne ihre Leseseite zu beeinflussen. Ein Client kann das Senden beenden und weiter auf eine Antwort warten. Ein Server kann seine Ausgabe beenden und weiter empfangen. Ein einzelner Alert ist weder ein symmetrischer Verbindungsabbau noch eine Abstimmung über einen verteilten Commit.

Jede Partei muss close_notify vor dem Schließen ihrer Schreibseite senden, sofern sie nicht bereits einen Fehler-Alert gesendet hat. Sie muss jedoch nicht auf den Alert der Gegenstelle warten, bevor sie ihre Leseseite schließt; dadurch entsteht laut Spezifikation ein mögliches Verkürzungsrisiko. Zwei unabhängig gesteuerte Richtungen erzeugen zwei Abschlussereignisse, keinen gemeinsamen Anwendungsbeleg.

Der Alert schützt das Ende des Kanals. Schließt der zugrunde liegende Transport vor close_notify, weiß der Empfänger nicht, ob sämtliche vom Gegenüber gesendeten Daten angekommen sind. Ein im aktuellen Verbindungszustand geschützter Abschluss unterscheidet ein geordnetes Ende vom ungeklärten Verlust des Stromendes. Das ist ein wertvoller Nachweis, sagt aber nichts darüber aus, was die empfangende Anwendung mit den zuvor gelieferten Daten tat.

Das IANA-Register der TLS-Parameter weist close_notify einen Alert-Beschreibungscode zu. RFC 9846 stellt außerdem die Pflicht wieder her, ihn mit dem historischen Level warning zu senden. „Warning“ bedeutet weder optional noch geschäftlich erfolgreich. Sendevorgabe, Alert-Schwere und Anwendungsergebnis beantworten verschiedene Fragen. Fehler-Alerts schließen abrupt und verhindern weitere Daten; sie sind kein Ersatz für geordneten Abschluss.

TLS 1.3 beseitigt zudem eine schädliche Kopplung älterer Fassungen. Früher konnte der Empfänger eines close_notify gezwungen sein, ausstehende Schreibdaten zu verwerfen, sofort zu antworten und zu schließen. Dadurch wurde seine noch benötigte Senderichtung abgeschnitten. Die heutige Regel hält Lesen und Schreiben getrennt, sodass ein Nutzungsprofil relevante Ausgabe abschließen kann.

Eine Anwendung darf beim Empfang des Alerts ihren Sendepuffer leeren und sofort antworten. RFC 9846 warnt jedoch, dass ein Angreifer durch Verzögerung des Alerts oder der Anwendungspakete beeinflussen kann, was die Gegenstelle erhält. Deshalb braucht die Anwendung eigene Regeln: etwa nach eingeleitetem Abschluss keine neuen Eingaben anzunehmen oder vor einer Ergebnisentscheidung eine vollständige Anwendungsantwort zu verlangen.

Hier liegt die Trennung zwischen Lieferreihenfolge und Wirkungsautorität. TLS schützt Records und gibt ihrer Folge ein authentisiertes Ende. Ein zuverlässiger geordneter Transport trägt die Annahme, dass beim Schließen der Schreibseite ausstehende Daten vor der Zerstörung der Verbindung ausgeliefert werden. Keine dieser Schichten definiert den Anwendungsparser, prüft eine Transaktionskennung, vergibt einen Idempotenzschlüssel, bestätigt Speicherung oder stellt einen Geschäftsbeleg aus.

RFC 9293 beschreibt das TCP-Modell unter vielen TLS-Verbindungen, einschließlich des einseitigen Schließens. RFC 9110 und RFC 9112 definieren darüber HTTP-Semantik und HTTP/1.1-Nachrichtenrahmung. Die Schichten lassen sich zusammensetzen, ihre Abschlussbedingungen bleiben dennoch getrennt.

Bei HTTP könnte der maßgebliche Nachweis aus einer endgültigen, der Anfrage zugeordneten Antwort, einem vollständig gerahmten Body und den anwendbaren Statusregeln bestehen. Eine Warteschlange benötigt vielleicht die Bestätigung nach dauerhafter Ablage, eine Zahlung einen fachlichen Beleg mit stabiler Vorgangskennung. Nichts davon steckt in einem TLS-Abschluss-Alert.

Auch der Umkehrschluss ist falsch. Ein fehlendes close_notify beweist kein Scheitern der Anwendung. Diese kann bereits committed und einen Beleg gesendet haben, bevor der Transport verschwand. Es fehlt dann die TLS-Verkürzungssicherheit für die Richtung, nicht zwingend die Geschäftswirkung. Jede ungeordnete Trennung automatisch zu wiederholen, kann nicht-idempotente Effekte verdoppeln.

user_canceled ändert diese Einordnung nicht. In RFC 9846 bezeichnet der Alert einen Abbruch des Handshakes ohne Protokollfehler, muss von close_notify gefolgt werden und soll den Empfänger nicht vorzeitig vom Weiterlesen abhalten. Diese Meldungen beschreiben TLS-Zustand. Sie kodieren keine Rückzahlung, Bestellstornierung oder den Widerruf einer Anwendungseinwilligung.

Die Spezifikation belässt die Zuständigkeit für den Lebenszyklus beim Nutzungsprofil. Erlaubt ein Protokoll nach dem TLS-Ende Nicht-TLS-Daten auf demselben Transport, muss die Implementierung close_notify empfangen, bevor sie nach oben ein Datenende signalisiert. Allgemeiner schreibt RFC 9846 weder die Verwaltung des Transports noch die Zeitpunkte für das Öffnen und Schließen vor.

Diese Grenze verhindert Verallgemeinerungen. RFC 9001 nutzt TLS für den QUIC-Handshake, ersetzt aber den TLS-Recordschutz und verwendet QUIC-eigene Abschlussmechanismen. RFC 9147 gibt DTLS 1.3 einen Datagrammkontext. Eine Kontrolle für einen geordneten TLS-Strom lässt sich nicht allein wegen gemeinsamer Kryptografie auf jeden Transport übertragen.

Identität bleibt ebenfalls separat. RFC 9525 erläutert, wie Anwendungsprotokolle die Prüfung einer Dienstidentität mit TLS festlegen. Ein geordneter Abschluss authentisiert keine Partei neu, verlängert keine Berechtigung, bestätigt keinen menschlichen Akteur und genehmigt keine letzte Nebenwirkung.

In einer Ereignisfolge liegen der letzte Anwendungsschreibvorgang, der letzte angenommene TLS-Record und der Alert oft eng beieinander. Nähe hilft bei der Untersuchung, ersetzt aber keinen kausalen Beleg. Ein Server kann schließen, nachdem er Arbeit eingereiht hat, bevor ein Worker committed, oder nachdem er die Ausführung verworfen hat. Nur der Anwendungszustand kennt das autoritative Ergebnis.

RFC 5116 liefert die gemeinsame Schnittstelle für authentisierte Verschlüsselung. Die Integrität von Chiffretext und Zusatzdaten ist keine Aussage über Geschäftsabsicht. Ein im Verbindungszustand authentisierter Alert gehört zum Kanal; ob ein entferntes Subsystem eine dauerhafte Handlung vollzog, benötigt einen eigenen Nachweis.

Der Publikationseintrag zu RFC 9846 und die Errata-Seite sichern Status und spätere Korrekturen; RFC 8446 bewahrt den abgelösten Text. Diese Quellen belegen die Normfassung, nicht Verbreitung, Herstellerverhalten oder einen beobachteten Vorfall.

Quellen