Zusammenfassung

  • RFC 8446 vom August 2018 verhandelt die tatsächliche TLS-1.3-Version über supported_versions. Die geerbten legacy_version-Felder tragen 0x0303, die TLS-1.2-Nummer; ihre isolierte Auswertung verfälscht die Verbindungsstatistik.
  • Ein TLS-1.3-fähiger Server, der TLS 1.2 verhandelt, muss ServerHello.random mit 44 4F 57 4E 47 52 44 01 beenden. Bei TLS 1.1 oder älter ist das letzte Byte 00. Ein TLS-1.3-Client muss den Handshake abbrechen, wenn er eine dieser Marken in einer älteren Server-Antwort findet.
  • RFC 7507 regelte 2015 einen anderen Rückweg: Ein Client kann einen Neuversuch mit niedrigerer Version durch TLS_FALLBACK_SCSV kennzeichnen, worauf ein höher leistungsfähiger Server inappropriate_fallback meldet. Die IANA führt beide Werte.

Die alte Nummer am Eingang

Wer bei TLS 1.3 nur ServerHello.legacy_version auswertet, kann eine TLS-1.2-Verbindung protokollieren, die nie stattgefunden hat. RFC 8446 lässt dort 0x0303 stehen und verlagert die Entscheidung nach supported_versions. Schon der Name des alten Felds beschreibt seine Aufgabe: das geerbte Nachrichtenformat erhalten, nicht die laufende Kryptografie bezeugen. Ein Überwachungssystem, das das Etikett für den Betriebszustand hält, schreibt die Sicherheitsakte falsch.

Die Ursache lag auf dem Weg zwischen den Endpunkten. Manche Zwischenstationen kannten die frühere Form der Verhandlung und ließen neue Muster scheitern. Anhang D.4 beschreibt dafür einen Kompatibilitätsmodus: Der Client liefert eine nicht leere Sitzungs-ID, und scheinbare ChangeCipherSpec-Nachrichten können den älteren Ablauf vorspiegeln. Wenn die Endpunkte TLS 1.3 in der Erweiterung auswählen, arbeiten sie mit TLS 1.3. Die alte Kleidung soll die Geräte dazwischen passieren.

Diese Geräte hatten dadurch faktisch ein Veto, ohne an der Sicherheitsentscheidung beteiligt zu sein. Wer unbekannten Verkehr verwerfen kann, erzwingt Änderungen an der äußeren Form eines neuen Protokolls. Die Norm kam den Erwartungen installierter Technik im sichtbaren Datenstrom entgegen und ließ die entscheidende Versionsangabe bei den Endpunkten. Sichtbare Verpackung und ausgeführter Zustand sind verschiedene Tatsachen.

Der Hinweis am Ende des Zufallswerts

Neben der äußerlichen Kompatibilität gab es den Versuch, die Verbindung aktiv auf eine ältere Version zu drücken. Ein TLS-1.3-fähiger Server, der TLS 1.2 wählt, muss die letzten acht Byte von ServerHello.random durch 44 4F 57 4E 47 52 44 01 ersetzen. Wählt er TLS 1.1 oder weniger, setzt er die gleiche Sieben-Byte-Folge mit 00 am Ende. Die ersten sieben Byte schreiben in ASCII DOWNGRD; das letzte markiert die niedrigere Versionsgruppe.

Ein TLS-1.3-Client muss bei einem ServerHello mit TLS 1.2 oder weniger nach beiden Folgen suchen. Bei Übereinstimmung beendet er den Handshake mit illegal_parameter. Die Marke zeigt, dass der Server eine höhere Version beherrschte, obwohl die sichtbare Aushandlung niedriger ausfiel. Ein funktionierender Altversionskanal beantwortet nicht, weshalb zwei fähige Endpunkte ihre bessere gemeinsame Möglichkeit liegen ließen.

RFC 8446 grenzt den Schutz ein. Die Marke bietet begrenzte zusätzliche Sicherheit über den Finished-Austausch hinaus. Bei ephemeren Chiffren bindet die Signatur im älteren Handshake die Zufallswerte; statisches RSA bietet diese Absicherung nicht. Die RFC hält auch fest, dass viele bereits eingesetzte TLS-1.2-Systeme der neuen Regel praktisch nicht folgen würden. Die acht Byte wirken nur, wenn ein fähiger Server sie schreibt und ein fähiger Client sie prüft.

Das Signal aus einem anderen Rückzug

Die RFC 7507 hatte 2015 einen Schritt des Clients im Blick. Nach einem gescheiterten Handshake versuchten manche Clients es aus Kompatibilitätsgründen erneut mit einer niedrigeren Version. Ein Angreifer, der Fehler auslösen konnte, konnte den Rückzug anschieben. Der Client kennzeichnet den Neuversuch mit TLS_FALLBACK_SCSV; der Server antwortet mit inappropriate_fallback, wenn er eine höhere Version unterstützt. Das TLS-Register der IANA dokumentiert Kennwert und Warnung.

Das Zeichen von 2015 kommt vom erneut anfragenden Client. Die Marke von 2018 liegt im Zufallswert eines Servers, der TLS 1.3 kann. Sie offenbaren Wissen verschiedener Teilnehmer zu verschiedenen Zeitpunkten. Wer beide bloß als „Downgrade-Schutz“ zusammenfasst, verliert die entscheidende Frage: Wer wusste beim Rückzug, dass eine bessere Version möglich war?

Wem gehörte die Verkleidung?

Anhang D.4 hält den Druck bereits installierter Infrastruktur auf einen neuen Standard fest. TLS 1.3 imitierte genug vom alten Handshake, um starre Zwischenstationen zu überwinden. Die Marke in ServerHello.random zog eine zweite Grenze: Eine äußerliche Konzession darf kein stillschweigendes Einverständnis mit erzwungener Schwächung werden. Die Endpunkte behielten die Versionsentscheidung und eine prüfbare Spur der niedrigeren Wahl eines fähigen Servers.

Die offiziellen Texte und Register belegen die Regeln. Für eine einzelne Verbindung wären datierte Paketmitschnitte und Implementierungsdaten beider Endpunkte nötig, um den Kompatibilitätsmodus und die Marke nachzuweisen. Der historische Befund steht: 2018 legte TLS 1.3 die echte Wahl in eine Erweiterung, ließ am Eingang eine alte Nummer stehen und verlangte am Ende eines fähigen Server-Zufallswerts einen Alarm, wenn es rückwärts ging.