Zusammenfassung

  • Die alte TLS-Neuverhandlung konnte zwei Handshakes auf einer bestehenden Verbindung ohne kryptografische Bindung aneinanderreihen. RFC 5746 ergänzte diese Bindung und ein Übergangssignal.
  • TLS 1.3 entfernte die Neuverhandlung, aber die RFCs belegen weder eine universelle Implementierung noch die vollständige Ausmusterung unsicherer Altpfade.

Der Fehler lag an einer fehlenden Grenze

TLS 1.2 erlaubte eine weitere Handshake-Phase auf einer bereits bestehenden Verbindung. In der ursprünglichen Konstruktion fehlte eine kryptografische Aussage, die den neuen Handshake an den vorherigen band. Das bedeutete: Der Server konnte den Anwendungskontext der bestehenden Verbindung fortführen, während eine neue Identität ausgehandelt wurde. RFC 5246 beschreibt die ursprüngliche TLS-1.2-Neuverhandlung; RFC 5746 dokumentiert die spätere Sicherheitslücke und ihre Reparatur.

Der dokumentierte Angriffsweg war präzise, nicht grenzenlos. Ein Angreifer stellte zunächst eine TLS-Verbindung her und platzierte von ihm gewählte Bytes am Anfang des Anwendung-Datenstroms. Danach wurde der Handshake eines Opfers als Neuverhandlung über dieselbe Serververbindung weitergeleitet. Der Server konnte das Opfer im neuen Handshake authentifizieren, während die zuvor platzierten Bytes im selben Anwendungskontext verblieben. Die IETF beschrieb die Folge als begrenzte Präfix-Injektion: Die praktische Wirkung hing davon ab, wie das jeweilige Anwendungsprotokoll die Bytes interpretierte. Das ist kein Nachweis für Entschlüsselung des geschützten Verkehrs oder für beliebige spätere Änderungen. RFC 5746 und RFC 7457 grenzen den Mechanismus entsprechend ein.

RFC 5746 reparierte zwei verschiedene Dinge

Die Reparatur bestand nicht nur aus einem allgemeinen Kompatibilitätssignal. RFC 5746 führte renegotiation_info ein, um Verifikationsdaten aus dem vorherigen Handshake in die Neuverhandlung einzubeziehen. Dadurch konnte die neue Handshake-Phase kryptografisch an die alte gebunden werden. Zusätzlich konnte ein Client während des initialen Handshakes mit TLS_EMPTY_RENEGOTIATION_INFO_SCSV signalisieren, dass er sichere Neuverhandlung unterstützt. Das Signal zeigte Unterstützung an; die vorherigen Finished-Verifikationsdaten stellten die eigentliche Bindung her. RFC 5746

Damit verschob sich die Verantwortung entlang einer Kette. Das Standardisierungsgremium definierte Wire-Format, Prüfungen und Übergangsverhalten. Bibliotheks- und Produkthersteller mussten diese Regeln implementieren und sichere Richtlinienoptionen anbieten. Betreiber mussten entscheiden, ob alte Neuverhandlung noch toleriert, eingeschränkt oder abgewiesen wird. Die Best-Practice-Empfehlungen hielten diese Kontrollen für ältere TLS-Versionen aufrecht. RFC 7525 behandelte die sichere Nutzung von TLS und DTLS; RFC 9325 ersetzte diese Empfehlung später und bewahrte die Hinweise für ältere Protokollversionen.

TLS 1.3 entfernte die Funktion – nicht automatisch jede Altlast

TLS 1.3 führte keine allgemeine Neuverhandlung fort. Stattdessen definierte es engere Funktionen nach dem initialen Handshake, darunter KeyUpdate und die Post-Handshake-Authentifizierung. RFC 8446 beschreibt diese Architektur; RFC 9325 erkennt ebenfalls an, dass TLS 1.3 die Neuverhandlung entfernt.

Das ist eine wichtige architektonische Verbesserung, aber kein Bereitstellungszensus. Ein TLS-1.3-Frontend beweist nicht, dass ein interner Dienst-Hop, ein Terminierungsgerät, eine ältere Bibliothek oder ein nachgelagerter Anwendungspfad ebenfalls TLS 1.3 verwendet. Ebenso beweist die Unterstützung von RFC 5746 nicht, dass unsichere Alt-Neuverhandlung dort, wo sie nicht mehr akzeptiert werden sollte, tatsächlich zurückgewiesen wird.

Was als Schließungsnachweis gelten würde

Die RFCs zeigen den Mechanismus und die Reaktion der Standards. Sie zeigen nicht den aktuellen Zustand eines bestimmten Betreibers, Produkts, Endpunkts oder Middleboxes. Eine belastbare Schließung müsste deshalb mehrere Kontrollflächen getrennt belegen:

  • externe Endpunkte und interne Dienstverbindungen testen;
  • TLS-Bibliotheken, Produkte, Appliances und Terminierungsschichten inventarisieren;
  • Ausnahmen mit verantwortlicher Person, betroffener Abhängigkeit, Kompensationsmaßnahme und Ablaufdatum dokumentieren;
  • Unterstützung für sichere Neuverhandlung von der tatsächlichen Ablehnung unsicherer Altlogik unterscheiden;
  • die Anwendungspfade prüfen, in denen ein eingeschobenes Präfix Autorisierung oder Anfrageinterpretation beeinflussen könnte;
  • Messungen wiederholen, damit nach Plattform- oder Lieferantenwechseln wiederentdeckte Altpfade sichtbar werden.

Die entscheidende offene Frage lautet daher nicht, ob die IETF eine Reparatur veröffentlicht hat. Das ist durch die RFC-Kette belegt. Die offene Frage lautet, welche überprüfbaren Nachweise zeigen, dass die Reparatur über den gesamten Dienstpfad wirksam bleibt und alte Ausnahmen tatsächlich verschwunden sind.