Zusammenfassung

  • CertificateVerify signiert das Transkript mit dem Zertifikatsschlüssel; Finished authentisiert eine spätere Grenze mit einem Schlüssel aus dem Handshake-Traffic-Secret des Senders.
  • Ein gültiges Server-Finished belegt weder Client-Finished noch 0-RTT-Annahme, Proxy-Upstream, Anwendungsberechtigung oder dauerhaften Erfolg.

Der Erfolg kam eine Nachricht zu früh

Kette, Dienstname und CertificateVerify waren gültig. Danach passte verify_data nicht zum lokal berechneten Transkript und Schlüssel. RFC 9846 verlangt einen fatalen Abbruch. Es gab keine halbwegs gültige Sitzung, sondern einen gescheiterten Handshake.

CertificateVerify beweist Kontrolle über den privaten Schlüssel der Credential und signiert eine rollenspezifische Konstruktion bis Certificate. Pfad- und Identitätspolitik bleiben getrennt.

Finished ist keine zweite Zertifikatssignatur. TLS 1.3 leitet finished_key aus dem Handshake-Traffic-Secret des Senders ab und berechnet einen HMAC über das Transkript einschließlich CertificateVerify, falls vorhanden. Damit werden berechnete Schlüssel und genau diese Verbindungsgeschichte bestätigt.

Bei PSK können Certificate und CertificateVerify fehlen, Finished aber nicht. Die Belege sind nicht austauschbar.

Das Transkript folgt Nachrichten, nicht Paketen

Der Hash enthält Handshake-Nachrichten samt Typ und Länge in Reihenfolge, nicht Record-Header, Alerts oder Anwendungsdaten. Fragmentierung ändert das logische Objekt nicht.

HelloRetryRequest ersetzt den ersten ClientHello durch einen synthetischen message_hash. Da spätere TLS-1.3-Handshakes verschlüsselt sind, braucht eine genaue Rekonstruktion Endpoint-Geheimnisse in einer kontrollierten Diagnose oder gleichwertige Implementierungsbelege.

Der Suite-Hash steuert Transkript und HKDF. verify_data ist in TLS 1.3 so lang wie dessen Ausgabe, nicht fix zwölf Byte wie in TLS 1.2.

Abschluss ist richtungsbezogen

Client und Server besitzen getrennte Secrets, erzeugen eigene Finished-Werte und prüfen den Peer zu unterschiedlichen Zeiten. Nach seinem Finished darf der Server Anwendungsschlüssel verwenden und Daten senden, bevor Client-Finished eintrifft. Dann fehlen ihm noch Zusicherungen über Identität und Lebendigkeit des Clients.

Der Client prüft Server-Finished, sendet bei Bedarf eigene Authentisierung und zuletzt Finished. Ein einziges tls_complete verschweigt, wer was gesendet oder geprüft hat. Pro Endpoint gehören finished_sent, peer_finished_verified und der getestete Laufzeitstatus ins Ledger.

0-RTT ist eine ausdrückliche Ausnahme. Es beruht auf früherem PSK und ist replaybar. Angebot, Annahme oder Ablehnung von Early Data bleiben vom normalen Abschluss getrennt.

Proxy-Beine teilen keine Geschichte

Client–Proxy und Proxy–Origin besitzen verschiedene Transkripte, Secrets und Finished. Ein Downstream-Label auf Upstream zu übertragen erfindet Kontinuität. Anwendungskorrelation kann Anfragen verbinden, aber jedes Bein braucht seinen eigenen kryptografischen Beleg.

OpenSSL trennt SSL_is_init_finished() von SSL_get_verify_result(), das nur Zertifikate beschreibt. Key Logging unterstützt Labordiagnosen, erzeugt aber sensitive Geheimnisse. BoringSSL dokumentiert für TLS 1.3 null aus Finished-Accessoren; GnuTLS bietet Hooks und einen eigenen Fehler. API-Namen sind kein portabler Nachweis.

Der entscheidende Test lässt Zertifikat und CertificateVerify gültig, ändert ein Finished-Byte und fordert fatalen Abbruch. Danach fehlen Client-Finished, Zertifikate im PSK-Fall, ein einfacher Transcript-Pfad nach HelloRetryRequest und gemeinsame Parameter zwischen Proxy-Beinen. Nur Laufzeitverhalten beweist die Grenze.