Zusammenfassung

  • TLS 1.2 erlaubte einen neuen Handshake innerhalb einer bestehenden Verbindung, band ihn aber nicht an den unmittelbar vorherigen Handshake.
  • RFC 5746 speicherte die verify_data-Werte des letzten Handshakes und ließ sie bei der Renegotiation prüfen.

Zwei gültige Handshakes, ein falsches Gespräch

Der Angriff begann mit einer legitimen TLS-Verbindung, die der Angreifer zum Server aufbaute. Er schickte ausgewählte Anwendungsdaten und leitete danach den Handshake eines Opfers über diese bereits geschützte Verbindung. Für das Opfer sah das wie ein initialer Handshake aus; für den Server konnte es wie eine Renegotiation der Verbindung des Angreifers wirken.

Der Angreifer konnte den späteren geschützten Datenverkehr nicht lesen. Das bereits übertragene Präfix blieb jedoch erhalten. Der Server konnte die Bytes des Angreifers und die anschließend authentisierten Daten des Opfers als eine einzige Anwendungskommunikation behandeln. Bei HTTPS konnte eine Anwendung ohne klare Zustandsgrenze die Eingabe des Angreifers mit später gelieferten Zugangsdaten oder Cookies verbinden.

Keine Chiffre war gebrochen und kein Zertifikat gefälscht. Beide Handshakes konnten gültige Finished-Nachrichten besitzen. Es fehlte die Verbindungsgarantie zwischen den Handshakes.

Den vorherigen Finished-Wert zum Verbindungszustand machen

RFC 5746 führte das Kennzeichen secure_renegotiation ein und speicherte pro Verbindung die Client- und Server-verify_data des unmittelbar vorherigen Handshakes. Diese Werte gehörten zur aktiven Verbindung, nicht lediglich zu einem wiederverwendbaren Sitzungscache.

Die Erweiterung renegotiation_info vom Typ 0xff01 übertrug diese Geschichte in die nächste Aushandlung. Beim initialen Handshake war renegotiated_connection leer. Bei einer Renegotiation sendete der Client sein gespeichertes client_verify_data; der Server verglich es mit seinem Zustand und gab die Verkettung aus Client- und Serverwert zurück. Der Client prüfte sie ebenfalls. Eine fehlende erforderliche Erweiterung oder eine Abweichung führte zum Abbruch mit einem fatalen Fehler.

Die daraus folgende Interpretation ist präzise: Ein erfolgreicher Handshake genügte nicht mehr. Er musste der richtige Nachfolger genau dieser Verbindung sein.

Ein Kompatibilitätssignal, das keine Chiffresuite war

Ältere Implementierungen konnten unbekannte Erweiterungen ablehnen. Deshalb definierte RFC 5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV mit 0x00,0xFF in der Chiffresuitenliste. Alte Implementierungen sollten unbekannte Suiten ignorieren, sodass ein Client seine Fähigkeit signalisieren konnte, ohne einen zuverlässigen Erweiterungsparser vorauszusetzen.

SCSV war weder eine aushandelbare Suite noch die Bindung späterer Renegotiations. Es war ein Signal des initialen Handshakes. Bestätigte der Server keine sichere Renegotiation, ließen sich Interoperabilität und eine Garantie gegen den Splice-Angriff nicht zugleich maximieren. TLS konnte allein auch nicht zwischen einer absichtlichen Ablehnung und einem ungepatchten Server unterscheiden.

Von der Reparatur zur Entfernung

TLS 1.3 zog eine andere Grenze: Renegotiation ist verboten. Ein späteres ClientHello auf einer TLS-1.3-Verbindung muss als unerwartete Nachricht behandelt werden. Eine mit einer älteren Version aufgebaute Verbindung muss diese Version beibehalten, wenn sie während einer Renegotiation ein TLS-1.3-ClientHello empfängt; auf diesem Weg kann sie nicht auf TLS 1.3 wechseln. KeyUpdate und Post-Handshake-Authentisierung sind eigene Mechanismen und keine Renegotiation.

Für TLS 1.2 verlangt RFC 9325, dass Clients und Server renegotiation_info implementieren; bestätigt der Server die Erweiterung nicht, muss der Client die Verbindung beenden. RFC 5746 löste nicht jedes Problem mit mehreren Handshakes; RFC 9325 behandelt das Extended Master Secret und das verwandte Triple-Handshake-Problem separat. Historisch entscheidend war die engere Änderung: Zeitliche Kontinuität wurde zu einer authentisierten Protokolleigenschaft statt zu einer Annahme der Anwendung.

Quellen