Zusammenfassung

  • NewSessionTicket übergibt dem Client eine opake PSK-Identität für einen künftigen Handshake. Ihre Annahme bindet eine neue TLS-Verbindung kryptografisch an den ausstellenden Handshake; sie belebt weder den alten Transport noch die heutige Gültigkeit von Anwendungsentscheidungen wieder.
  • Lebensdauer, verschleiertes Alter, Nonce, KDF-Hash, SNI, PSK-Modus und Binder beantworten jeweils eine begrenzte Frage. Keines dieser Felder beweist allein aktuelle Autorisierung, dasselbe Backend, 0-RTT-Annahme oder die Befugnis, eine frühere Geschäftsentscheidung weiterzuverwenden.
  • Nachweisbare Wiederaufnahme braucht einen versionierten Zustandsvertrag, begrenzte Schlüssel- und Dienstdomänen, eine eigenständige 0-RTT-Entscheidung, erneute Prüfung veränderlicher Befugnisse und einen beobachtbaren Rückfall auf den vollständigen Handshake.

Der korrekte Handshake mit dem veralteten Ergebnis

Das Ticket war sechs Stunden alt. Der Ersatzknoten konnte es entschlüsseln, fand den zugehörigen Zustand und beendete den Handshake als wiederaufgenommen. Im Identitätssystem war die privilegierte Rolle inzwischen widerrufen.

Die Anwendung fragte diese Quelle nicht ab. Sie las die im Ticketzustand gespeicherte Rolle und behandelte resumed=true als aktuelle Zugriffsentscheidung. TLS hatte nicht die Rolle bestätigt, sondern den Besitz eines aus dem früheren Handshake abgeleiteten Geheimnisses.

Zwei Uhren wurden gleichgesetzt. Die kryptografische Richtlinie ließ den PSK noch zu; die Autorisierungsrichtlinie hatte die Befugnis bereits beendet. Authentizität verhindert unbemerkte Änderung, nicht das Altern einer Aussage.

Ein Ticket bezeichnet einen neuen PSK

TLS 1.3 ersetzt ältere Sitzungsmechanismen durch einen gemeinsamen PSK-Austausch. Nach dem Finished des Clients kann der Server NewSessionTicket senden. Jede Nachricht ordnet den opaken Ticketwert einem PSK zu, der aus dem Wiederaufnahmegeheimnis und einem eindeutigen ticket_nonce abgeleitet wird.

Der Wert kann ein Datenbankschlüssel sein, sodass der Zustand beim Server verbleibt. Er kann auch selbstverschlüsselten und selbstauthentisierten Zustand transportieren. In beiden Fällen ist er auf Protokollebene eine PSK-Identität, nicht der alte Verkehrsschlüssel und nicht die alte Verbindung.

Ein Server darf mehrere Tickets für parallele Verbindungen oder Rennen zwischen Schnittstellen ausgeben. Unterschiedliche Nonces erzeugen unterschiedliche PSKs. Das Betriebsprotokoll muss daher Ausstellung und Schlüsselepoche unterscheiden, statt alles als „dieselbe Sitzung“ zusammenzufassen.

Die Wiederaufnahme schafft ein neues Transkript, neue Verkehrsschlüssel und neue Record-Zähler. Socket, Prozessspeicher, Anwendungstransaktion und Netzwerkpfad werden nicht restauriert.

Die Lebensdauer ist keine Annahmegarantie

ticket_lifetime beginnt mit der Ausstellung und ist auf sieben Tage begrenzt. Null bedeutet sofortiges Verwerfen. Der Client darf früher löschen; der Server darf eine kürzere tatsächliche Gültigkeit anwenden.

Das Feld begrenzt, wie lange ein Client den Versuch unternehmen darf. Es verpflichtet den Server nicht, das Ticket bis zum letzten Augenblick anzunehmen. Schlüsselrotation, Datenbanklöschung, engere Dienstdomäne, Widerruf oder neue Richtlinie können vorher einen vollständigen Handshake verlangen.

ticket_age_add addiert einen zufälligen Wert zum Alter, um passive Korrelation zu erschweren. Der Server zieht ihn ab und vergleicht mit der verstrichenen Zeit. Eine Kopie des Tickets besitzt dieselbe Rechnung; daraus wird kein aktives Einmal- oder Anti-Replay-Merkmal.

Liegt das Alter außerhalb der Toleranz, sollte der Server 0-RTT ablehnen und keine Frische des ClientHello annehmen. Die gewöhnliche Wiederaufnahme kann trotzdem gelingen. Entschlüsselung, PSK-Auswahl, Wiederaufnahme und frühe Daten sind getrennte Ergebnisse.

Der Binder beweist eine Geheimniskette

Der Client bietet PSK-Identitäten und zugehörige Binder im ClientHello an. Ein Binder bindet den PSK an den aktuellen Handshake und über das Wiederaufnahmegeheimnis transitiv an den ursprünglichen Handshake.

Dieser Beweis ist stark und eng. Er bestätigt nicht, dass ein Konto aktiv, ein Gerät weiterhin vertrauenswürdig, ein Abonnement gültig oder eine Risikobewertung unverändert ist. Eine unverfälschte Aussage kann veraltet sein.

Bei PSK-authentisierter Wiederaufnahme sendet der Server Certificate und CertificateVerify nicht erneut. Der frühere Authentisierungskontext leistet diese kryptografische Arbeit. Eine Anwendung muss daher festlegen, welche veränderlichen Fakten sie übernimmt und welche sie bei einer aktuellen Autorität nachfragt.

OpenSSL kann nach nachträglicher Clientauthentisierung neue Tickets ausgeben, die mit der aktualisierten Clientidentität verbunden sind. Diese neue Generation ändert ältere Tickets nicht rückwirkend. Ohne Generationsnachweis verliert ein Betreiber die Reihenfolge, die Widerruf erst durchsetzbar macht.

Der aktuelle Dienst behält seinen Namen

Der neue ClientHello trägt den aktuellen SNI. Der Client darf nur wiederaufnehmen, wenn das ursprüngliche Zertifikat für diesen Namen gültig war, und sollte normalerweise denselben SNI verwenden. Meldet die Bibliothek SNI an die Anwendung, muss sie den neuen Wert melden.

RFC 9525 bindet die Referenzidentität ebenfalls an den jetzt angeforderten Dienst. SNI und ALPN bezeichnen Dienst und Protokoll. Ein entschlüsselbares Ticket ist keine pauschale Autorisierung für alle Namen, Mandanten oder Protokolle derselben Infrastruktur.

Ein gemeinsamer Umhüllungsschlüssel über Regionen verbessert Failover und erweitert zugleich die Menge der Knoten, die alten Zustand auslegen können. BoringSSL behandelt Wiederaufnahme über Namen als ausdrückliche Richtlinie. Entschlüsselungsfähigkeit entscheidet die legitime Domäne nicht von selbst.

Auch der KDF-Hash setzt eine harte Grenze. Die neue Cipher Suite muss denselben KDF-Hash wie die ursprüngliche verwenden. Diese Kompatibilität ermöglicht Ableitung, friert aber weder Routing noch Berechtigung oder Anwendungsparameter ein.

Wiederaufnahme ist nicht frühe Ausführung

Ein Ticket kann die Erweiterung early_data und eine Bytegrenze tragen. Damit darf der Client 0-RTT anbieten. Der Server muss es nicht annehmen, und die Anwendung erhält dadurch keinen Beweis, dass eine Operation Replay verträgt.

Die Telemetrie braucht drei getrennte Ereignisse: Ticket gefunden oder entschlüsselt, PSK für den Handshake ausgewählt und 0-RTT angenommen. Zweifelhafte Alterswerte, fehlender Anti-Replay-Zustand oder veränderte Parameter können frühe Daten stoppen, während die normale Wiederaufnahme gelingt.

HTTP 425 wirkt an einer späteren Grenze. Der Origin kann die Ausführung einer Anfrage mit Frühdatenherkunft verweigern. Das bestimmt nicht, welche Zustandsautorität das Ticket selbst trägt. Das Problem dieses Berichts bleibt bei vollständig deaktiviertem 0-RTT bestehen.

QUIC ergänzt Kontinuitätsprüfungen für Transport- und Anwendungsparameter. Ein gültiges TLS-Ticket beweist nicht, dass alte QUIC-Grenzen oder HTTP/3-SETTINGS weiterhin kompatibel sind.

Das Speichermodell verteilt Annahmebefugnis

Ein datenbankgestütztes Ticket kann nach Gebrauch gelöscht, als verbrauchbare Identität protokolliert und auf einen Autoritätsspeicher begrenzt werden. Datenbankverfügbarkeit und Replikationskonsistenz werden jedoch Voraussetzungen der Wiederaufnahme.

Ein selbstenthaltenes Ticket überlebt Knotenausfall leichter. Jeder Knoten mit dem Umhüllungsschlüssel kann seinen Zustand bis zur Schlüsselstilllegung auslegen. Schlüsselverteilung ist damit auch Verteilung von Annahmebefugnis.

Die Wahl lautet nicht „zustandsbehaftet sicher, zustandslos unsicher“. Sie wählt Fehlerdomänen. Replikationsverzug kann doppelte Annahme oder falsche Ablehnung verursachen. Weit verteilte Schlüssel und lange Epochenüberlappung können veralteten Zustand länger interpretierbar halten.

OpenSSL stellt Entschlüsselungsstatus, Schlüsselnamen, Ticket-Anwendungsdaten, Ausgabemenge und Unterdrückung bereit. GnuTLS bietet Ticket-Schlüssel und zusätzliche Ausgabe. BoringSSL erzeugt neue Alterswerte, begrenzt die Anzahl und prüft frühe Daten separat.

Diese Schnittstellen beweisen eine Steuerungsfläche. Sie beweisen nicht die geladene Epoche, abgeschlossene Rotation, gespeicherte Claims oder erneute Autorisierungsprüfung.

Versionierte Referenzen statt ewiger Wahrheiten

PSK-Identität, KDF-Hash, Wiederaufnahmemodus und eine begrenzte Referenz auf den authentisierten Handshake sind relativ stabile kryptografische Fakten. Benutzerrolle, Gerätevertrauen, Abonnement und Mandantenroute ändern sich.

Eine Anwendung kann Benutzer-ID und Autorisierungsversion mitführen und vor Zugriff mit der aktuellen Quelle vergleichen. Sie kann einer Route Ablauf und Version geben oder nach geänderter Clientauthentisierung eine neue Ticketgeneration ausgeben.

Gefährlich ist das Speichern bloßer Ergebnisse: administrator=true, „Gerät vertrauenswürdig“, „Abonnement aktiv“. Verschlüsselung schützt vor heimlicher Manipulation. Sie macht die Wahrheit von gestern nicht zur Wahrheit von heute.

EAP-TLS verwendet ein oder mehrere Tickets zur Authentisierungswiederaufnahme und beachtet die Sieben-Tage-Grenze. Das Profil muss definieren, was Wiederaufnahme bedeutet und welches Ereignis sie ungültig macht. TLS transportiert den Zustand; die Einsatzumgebung entscheidet über heutigen Zugang.

Belege, die ein Failover überstehen

Zu erfassen sind ein datenschutzgerechter Korrelationswert oder Schlüsselname, Ausgabeknoten und Region, Ausgabezeit, deklarierter und wirksamer Ablauf, Epoche, Speichermodell, KDF-Hash und PSK-Modus. Beim Angebot folgen Alter, Entschlüsselungsresultat, gewählter Index, aktueller SNI und ALPN, Ergebnis und Rückfallgrund.

0-RTT wird getrennt erfasst: angeboten, kryptografisch zulässig, angenommen oder abgelehnt, Bytegrenze, Anti-Replay-Zustand und Anwendungsentscheidung. resumed=true darf niemals stillschweigend early_data_accepted=true bedeuten.

Für Geschäftszustand gehören Schema-, Autorisierungs-, Widerrufs- und Routingversion sowie die Quelle jeder aktuellen Entscheidung in den Nachweis. Die Korrelation verbindet Ausgabe und Annahme, ohne Ticket oder PSK zu protokollieren.

Negativtests decken Ablauf, serverseitig verkürzte Gültigkeit, unbekannte oder stillgelegte Schlüssel, Authentisierungsfehler, gelöschte Datenbankzeile, regionale Wiederverwendung, SNI/ALPN-Wechsel, unvereinbaren KDF-Hash und einen widerrufenen Benutzer mit weiterhin entschlüsselbarem Ticket ab.

Auch der Rückfall muss bewiesen sein. Nach Ticketablehnung soll ein vollständiger Handshake gelingen, wenn die Richtlinie es erlaubt. Eine Notfallmaßnahme muss eine Epoche oder Zustandsversion stilllegen können, ohne fremde TLS-Dienste zu unterbrechen.

Quellen