Zusammenfassung

  • Finished bestätigt das aktuelle Handshake-Transkript unter dem ausgehandelten Geheimnis; Anwendungsdaten vor einer Neuverhandlung werden dadurch nicht mitbewiesen.
  • RFC 5746 trägt frühere verify_data in den neuen Handshake und bindet ihn an den Vorgänger. Principal-Wechsel, Puffer, Autorisierung, Commit und Außenwirkung brauchen eigene Nachweise.

Ein gültiger Handshake auf einem fremden Satzanfang

Die Verbindung führt bereits geschützte Daten. Ein neuer ClientHello startet, der Server fordert vielleicht ein Client-Zertifikat an, Schlüssel wechseln und Finished wird akzeptiert. Die TLS-Schicht meldet Erfolg.

In RFC 5246 hängt verify_data vom Master Secret und den Handshake-Nachrichten ab. Die Prüfung zeigt, dass beide Seiten dasselbe Verhandlungstranskript und denselben Schlüsselzustand besitzen. Normale Anwendungsdaten gehören nicht zum Transkript.

Ursprünglich fehlte außerdem die kryptografische Bindung des zweiten Handshakes an die vorherige Verbindung. Ein Vermittler konnte eine Verbindung öffnen, ein Anwendungspräfix senden und anschließend den authentisierten Handshake eines anderen Teilnehmers anschließen. Der Server konnte Präfix und Fortsetzung als eine Anfrage lesen. Der Handshake war echt; die zugeschriebene Unterhaltung nicht.

Ein Socket ist kein unveränderlicher Principal

TLS 1.2 unterscheidet aktuellen und ausstehenden Zustand. Der Handshake bereitet Algorithmen und Geheimnisse vor. ChangeCipherSpec aktiviert den neuen Zustand. Finished prüft ihn unter den neuen Schlüsseln.

Damit ist festgelegt, was spätere Records schützt. Nicht festgelegt ist, ob eine halb gepufferte anonyme Anfrage nach der Zertifikatsprüfung als authentisierte Anfrage weiterlaufen darf. Der Dateideskriptor bleibt gleich, die Autoritätsgrundlage im Inneren kann wechseln.

Wenn der TLS-Terminator nur den neuesten Principal exportiert, erben alte Bytes eine neue Identität. Jede lokale Komponente kann dabei korrekt arbeiten und die Zusammensetzung dennoch eine nie getroffene Berechtigungsentscheidung erzeugen.

Die rückwärts gerichtete Naht von RFC 5746

Secure Renegotiation führt renegotiation_info und TLS_EMPTY_RENEGOTIATION_INFO_SCSV ein. Im ersten Handshake zeigen leere Werte die Unterstützung. Bei der Neuverhandlung enthält die Erweiterung die vorherigen Finished-verify_data von Client und Server.

Der neue Handshake muss damit eine Ausgabe des alten kennen. Stimmen die Werte nicht mit der gehaltenen Verbindung überein, kann die Neuverhandlung verworfen werden. Kontinuität wird nicht länger aus demselben Socket vermutet, sondern zwischen zwei Handshakes geprüft.

Unterstützung ist trotzdem kein Laufzeitbeleg. Eine Bibliothek kann die Erweiterung implementieren, während Policy jede Neuverhandlung sperrt. SCSV allein beweist keinen zweiten Handshake. Inventar, geladene Konfiguration, Signal, Peer-Antwort, tatsächlicher Vorgang und Wertvergleich müssen getrennt bleiben.

Der sichere Kanal entscheidet keinen Nachrichtenbesitz

RFC 5746 definiert nicht, was mit einer begonnenen Nachricht beim Principal-Wechsel geschieht. Verwerfen, unter alter Identität abschließen oder mit einer neuen vollständigen Nachricht starten sind Anwendungsentscheidungen.

Jede geparste Anfrage sollte Security-Generation und Principal tragen. Der Wechsel braucht eine explizite Pufferregel. Ein erfolgreiches Finished darf ältere Bytes nicht rückwirkend autorisieren.

Channel Bindings nach RFC 5929 können Eigenschaften des Kanals in übergeordnete Authentisierung einbringen. Das Erzeugen des Werts und seine korrekte Verwendung im Anwendungsprotokoll sind jedoch zwei verschiedene Belege.

EMS repariert eine andere Beziehung

Extended Master Secret aus RFC 7627 leitet das Master Secret aus einem Hash des Handshake-Transkripts ab und adressiert Session-Hash- und Triple-Handshake-Probleme. Es ersetzt RFC 5746 nicht.

EMS bindet ein Geheimnis an seinen Handshake. Secure Renegotiation bindet den neuen Handshake an die vorherige Verbindung. Das gemeinsame Etikett „TLS gehärtet“ löscht die Frage, welche Beziehung tatsächlich geprüft wurde.

Eine erklärbare Spur hält EMS, Secure-Renegotiation-Signal und -Ausführung, Bindewerte, Zertifikatspfad und erzeugten Principal auseinander, ohne Schlüsselmaterial zu protokollieren.

TLS 1.3 entfernt die Funktion, nicht automatisch den Bestand

TLS 1.3 kennt keine Neuverhandlung mehr. Die bewegliche Naht verschwindet. Ein Endpunkt mit TLS 1.3 kann dennoch TLS 1.2 anbieten; ein Proxy kann außen 1.3 und innen 1.2 sprechen. RFC 9851 friert die normale Funktionserweiterung von TLS 1.2 ein, schaltet aber keinen Listener ab.

Migration braucht Listener-Inventar, geladene Policy, beobachtete Verhandlungen, Eigentümer der Abhängigkeiten und Service-Canaries auf denselben Pfaden.

Solange Neuverhandlung existiert, sollte ein Gesprächsledger Anfangs-Handshake und Finished, Bytebereiche, Auslöser, sicheres Signal, Vorwertvergleich, neue Identität, Zustandsaktivierung, neues Finished, Principal Mapping, Nachrichtengrenze, Autorisierung, Commit und Außenwirkung verbinden.

Dieses Ledger ist BTW-Analyse und kein RFC-5246-Logformat. Es wahrt die Grenze eines starken kryptografischen Belegs gegenüber Entscheidungen, die er nicht beobachtet hat.

Quellen