Zusammenfassung

  • Ein Exported Authenticator verbindet Certificate, CertificateVerify und Finished mit Material aus genau einer bestehenden TLS/DTLS-Verbindung. Er beweist eine zusätzliche X.509-Identität, ändert aber keinen TLS-Zustand.
  • Er enthält weder Erstellungszeit noch Anwendungs-Stream. Ein eindeutiger Request Context begrenzt Wiederholung in der Verbindung; Vorgang, Wirkzeit und Berechtigung muss die Anwendung separat binden.
  • Belastbare Evidenz trennt Anfrage, Verbindungsbindung, Kryptografie, Zertifikatsrichtlinie, authentifizierte leere Ablehnung und Autorisierung. Ein TLS-Terminator bleibt eine harte Grenze, auch bei gleichem Zertifikat.

Kryptografisch gültig, historisch falsch

Die Verbindung begann um 13:58 Uhr mit ihrer gewöhnlichen Handshake-Identität. Fünf Minuten später validierte die Antwort auf eine zusätzliche Identitätsanfrage. Der Fehler war, daraus rückwirkendes Eigentum an der gesamten Verbindung abzuleiten.

RFC 9261 beschreibt unabhängige, unidirektionale Authenticators. Erzeugung und Prüfung ändern TLS nicht ausdrücklich. Der Nachweis kann eine künftige, benannte Berechtigungsänderung stützen. Er kann weder frühere Arbeit authentifizieren noch einen Stream oder Zeitpunkt erfinden.

Certificate präsentiert X.509, CertificateVerify beweist den privaten Schlüssel, Finished schützt das Konstrukt mit einem aus der Verbindung abgeleiteten Schlüssel. Es entsteht kein neuer Handshake und kein TLS-Record-Framing. Der Transport liegt bei der Anwendung und sollte gleichwertig geschützt sein.

TLS 1.3 nutzt exporter_master_secret, nicht den frühen Exporter. TLS 1.2 verlangt PRF und Extended Master Secret. Das Ergebnis lautet deshalb eng: Dieser Peer bewies auf dieser Verbindung diese akzeptable Identität. Es gilt nicht automatisch für eine andere Verbindung, alle Streams oder eine Geschäftsrolle.

Zertifikatsprüfung bleibt getrennt. Eine korrekte Signatur rettet kein abgelaufenes, unzulässiges oder rollenfremdes Zertifikat. Kryptografie, X.509-Vertrauen und Anwendungsrecht brauchen eigene Ergebnisse.

Eindeutiger Kontext, begrenzte Bedeutung

certificate_request_context ist bis zu 255 Oktette lang, muss über die RFC-9261-Anfrageformen innerhalb einer Verbindung eindeutig und sollte unvorhersagbar sein. Die Antwort wiederholt ihn; ein alter Nachweis kann dadurch keine zweite Anfrage erfüllen.

Der Wert ist keine globale Transaktion, Uhr, Konto- oder Stream-ID. Wenn Gateway, Identitätsdienst und Worker getrennte Zähler führen, können sie in derselben Verbindung kollidieren. Der Eigentümer der Eindeutigkeit muss die ganze Verbindung sehen.

Ein Zähler kann eindeutig, aber vorhersehbar sein; Zufallszustand kann nach Snapshot-Restore wiederkehren. Zu speichern sind Kontext-Hash, Generator-Epoche, Verbindung, Extensions, Ziel und lokale Zeit, niemals Exporter-Secrets oder private Schlüssel.

Clients brauchen eine vorherige Anfrage, Server dürfen spontan beweisen. Monitoring muss diese Asymmetrie behalten.

Verbindung ist nicht Stream

HTTP/2 multiplexiert viele Streams. RFC 9001 verbietet TLS Post-Handshake Client Authentication in QUIC, weil ein TLS CertificateRequest nicht zuverlässig dem auslösenden Anwendungsereignis zugeordnet werden kann.

Exported Authenticators verlagern Anfrage und Nachweis dorthin, wo eine Anwendung Korrelation ausdrücken kann. Sie erledigen sie nicht. Das obere Protokoll muss Context X, Stream 41, Vorgang Y und eine Barriere nach Validierung Z verbinden.

Der sichere Standard ist prospektiv und klein. Bereits bearbeitete Vorgänge, frühere Queues und Nachbar-Streams behalten ihre Identität. Eine verbindungsweite Anhebung benötigt ausdrücklich Ordnung, Reichweite und Rollback.

Erstellung, Empfang, Prüfung und Wirkung sind verschiedene Zeiten. Im Authenticator steckt kein Erstellungszeitstempel. Ein einziges authenticated_at verdeckt Verzögerung und Replay.

Der TLS-Terminator erzeugt eine neue Grenze

Der Handshake Context stammt aus der Anfangsverbindung. Ein auf A erzeugter Nachweis scheitert bei Prüfung gegen B. Ein terminierender Proxy besitzt zwei Kontexte, auch mit derselben Kette.

Ein Fallback auf Zertifikatsgleichheit würde die zentrale Bindung entfernen. Identität über den Terminator braucht ein eigenes Delegationsprotokoll mit Aussteller, Zielgruppe, Ablauf und Verwahrung oder zwei unabhängige Nachweise samt eigener Vertrauensentscheidung.

Reconnect und Failover beenden ebenfalls die alte Grenze. Berechtigung wird neu bewiesen, abgesenkt oder durch einen eigens entworfenen Kontinuitätsmechanismus getragen.

Authentifizierte Ablehnung

Ohne geeignete oder gewünschte Identität kann der Peer einen empty authenticator senden: Finished bleibt, Certificate und CertificateVerify fehlen. Der MAC authentifiziert die Ablehnung, nicht eine Identität.

Dieser Zustand ist von Schweigen, Fehlformat, falscher Signatur und abgelehnter Kette zu trennen. Endloses Wiederholen macht eine legitime Ablehnung zur DoS-Schleife.

Vier Nachweisbücher

Verbindungsbuch: Version, Suite, Handshake, Peer Finished, EMS, nicht geheime ID. Anfragebuch: Rolle, Kontext-Hash, Eindeutigkeit, Extensions, Ziel, Zeit, Kanal. Prüfbuch: Modus, Certificate-Hash, Fingerprints, CertificateVerify, Finished, Verbindungsabgleich, X.509, leere Ablehnung, Zeiten. Autoritätsbuch: Entscheider, Stream/Vorgang, altes und neues Privileg, Wirkung, Ablauf, Rollback.

Eine Erfolgsquote kann trotz Kontextwiederverwendung und zu großer Reichweite steigen. Ein Wrong-Connection-Fehler kann dagegen den korrekten Schutz beweisen.

IANA registriert Labels; OpenSSL und BoringSSL zeigen den Exporter-Unterbau. Beides beweist weder RFC-9261-Einsatz noch richtige Autorisierung. Erst rekonstruierbare Ausführung macht die Spezifikation zur Betriebswirklichkeit.

Quellen