Zusammenfassung
- Die ursprüngliche TLS-Neuverhandlung führte einen zweiten Handshake im verschlüsselten Kanal aus, band beide Handshakes aber nicht kryptografisch zusammen.
- RFC 5746 machte die Finished-Nachweise des Vorgängers zum Bestandteil der nächsten Aushandlung; TLS 1.3 schaffte die Neuverhandlung ab.
Zwei Absender in einem Datenstrom
Der Angreifer baut zunächst selbst eine gültige TLS-Verbindung zum Server auf und sendet ein frei gewähltes Präfix auf Anwendungsebene. Das kann der Anfang einer Anfrage sein, deren Bedeutung erst durch spätere Bytes vollständig wird. Danach leitet er den neuen TLS-Handshake eines Opfers durch seine bereits geschützte Verbindung zum Server.
Für das Opfer ist dies der erste Handshake mit dem echten Server. Für den Server erscheint derselbe Vorgang als Neuverhandlung der Angreifer-Verbindung. Nach Abschluss kann der Angreifer den späteren Verkehr des Opfers nicht lesen. Versagt hat nicht jede Vertraulichkeit, sondern die Zuordnung: Der Server kann das Präfix des Angreifers und die authentisierten Bytes des Opfers zu einer Anwendungshandlung verbinden.
RFC 5746 trennte damit drei Eigenschaften. Eine fortbestehende Transportverbindung, eine fortbestehende Verschlüsselung und ein fortbestehender Anwendungstranscript sind nicht dasselbe. Der offene Socket beweist nicht, dass Bytes vor und nach einem Wechsel des kryptografischen Zustands denselben Urheber haben.
Der vorige Finished-Wert als Erinnerung
Die Reparatur speichert pro Verbindung ein Kennzeichen für sichere Neuverhandlung sowie die verify_data-Werte, die Client und Server in den Finished-Nachrichten des unmittelbar vorangegangenen Handshakes gesendet haben. Diese Werte bestätigen, dass beide Endpunkte genau diesen früheren Handshake gesehen haben.
Die Erweiterung renegotiation_info trägt den Typ 0xff01. Beim ersten Handshake ist ihr Bindungsfeld leer: Unterstützung wird signalisiert, ohne einen Vorgänger vorzutäuschen. Bei einer Neuverhandlung enthält der ClientHello den gespeicherten Client-Wert. Der ServerHello enthält Client- und Server-Wert hintereinander. Fehlt die Erweiterung oder stimmt ein Wert nicht mit der lokalen Erinnerung überein, muss der Handshake abgebrochen werden.
Der Angreifer kann den Handshake des Opfers weiterleiten, ihn aber nicht mit dem korrekten Nachweis seiner eigenen vorherigen Verbindung versehen. Sicherheit entsteht nicht daraus, dass der neue Handshake unter alten Schlüsseln transportiert wird. Sie entsteht daraus, dass er seinen Vorgänger authentisiert benennt.
Eine Reparatur mit Kompatibilitätsschulden
Einige alte Implementierungen brachen bei unbekannten ClientHello-Erweiterungen ab, obwohl sie diese hätten ignorieren müssen. RFC 5746 definierte deshalb zusätzlich TLS_EMPTY_RENEGOTIATION_INFO_SCSV. Der Wert steht in der Cipher-Suite-Liste, bezeichnet aber keine Algorithmen und kann nicht ausgehandelt werden. Er signalisiert lediglich dieselbe Fähigkeit wie eine leere anfängliche Erweiterung.
Die Übergangsphase blieb mehrdeutig. Ein Server ohne Bestätigung konnte unsichere Neuverhandlung erlauben oder jede Neuverhandlung ablehnen und deshalb ungefährdet sein. Der Client konnte die beiden Fälle mit TLS-Mitteln nicht unterscheiden. Abbruch bot die stärkere Garantie; Fortsetzung bewahrte mehr alte Gegenstellen. Die Abwesenheit eines Nachweises wurde zu einer bewussten Betriebsentscheidung.
TLS 1.3 entfernt statt repariert
RFC 8446 verbietet Neuverhandlung in TLS 1.3. Ein ClientHello zum falschen Zeitpunkt führt zum Verbindungsabbruch. Schlüsselaktualisierung und Authentisierung nach dem Handshake bleiben getrennte Mechanismen mit eigenen Grenzen; sie stellen die alte allgemeine Neuverhandlung nicht wieder her.
RFC 9325 hält für TLS 1.2 fest, dass Clients und Server renegotiation_info implementieren müssen und der Client ohne Bestätigung beenden muss. Die Quellen zählen weder reale Opfer des Jahres 2009 noch heutige Installationen. Sie belegen jedoch Fehler, Bindung und spätere Entfernung. Die dauerhafte Regel lautet: Ein Wechsel von Schlüssel oder Identität muss beweisen, welchen alten Zustand er übernimmt. Verschlüsselung allein liefert diesen Beweis nicht.
Quellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
