Zusammenfassung

  • Manche Clients wiederholten einen gescheiterten TLS-Handshake mit stufenweise älteren Versionen. Weil ein Angreifer im Übertragungsweg Fehler herstellen konnte, erhielt das Netz außerhalb der authentisierten Aushandlung Einfluss auf die Versionswahl.
  • POODLE nutzte anschließend die CBC-Paddingregeln von SSL 3.0 unter zusätzlichen Bedingungen aus: aktiver Vermittler, wiederholte Anfragen mit einem Geheimnis und veränderte Records. Die ursprüngliche Konstruktion erwartete etwa 256 SSL-3.0-Anfragen je gewonnenem Byte.
  • TLS_FALLBACK_SCSV verschlüsselte und authentisierte nichts. Es kennzeichnete einen ClientHello mit niedrigerer Version als Rückfall, damit ein höher befähigter Server ihn lokal mit inappropriate_fallback(86) abweisen konnte.

TLS besaß bereits eine Versionsaushandlung. Ein Client konnte TLS 1.2 anbieten, ein Server mit höchstens TLS 1.0 konnte TLS 1.0 antworten, und das Ergebnis wurde durch den Handshake geschützt. Das war der vorgesehene Weg.

Daneben entstand der Rückfalltanz. Browser- und Bibliotheksentwickler trafen auf alte Server und Middleboxes, die schon beim Anblick neuerer Versionen scheiterten. Um die Verbindung dennoch herzustellen, begannen manche Clients nach einem Fehler einen neuen Versuch mit niedrigerem Versionsmaximum und stiegen notfalls bis SSL 3.0 hinab.

Die Bequemlichkeit verbarg eine Kompetenzverschiebung. Der Fehler war nicht länger nur eine negative Beobachtung über einen Versuch. Er galt als Aussage über die Fähigkeit des Servers, obwohl dieser nichts Authentisiertes gesagt hatte. Wer die höherwertigen Versuche unterbrechen konnte, konnte dieselbe Aussage erfinden. TLS 1.2 musste nicht gebrochen werden; der Client bot es freiwillig nicht mehr an.

Damit war nur die Tür geöffnet. POODLEs Klartextgewinn brauchte zusätzlich die Bedingungen hinter der Tür.

Bei SSL 3.0 durften CBC-Paddingbytes beliebige Werte tragen, die nicht vollständig vom Nachrichtenauthentisierungscode geschützt waren. Das ursprüngliche Google-Papier beschrieb einen aktiven Vermittler, der den Browser zu wiederholten HTTPS-Anfragen mit Cookie veranlasste, ein Zielbyte an eine Blockgrenze rückte, den letzten Chiffretextblock ersetzte und aus der Annahme des veränderten Records lernte. Die Annahmechance lag für die geprüfte Bedingung durchschnittlich bei eins zu 256. Erwartet wurden daher 256 SSL-3.0-Anfragen pro Byte.

Die Zahl wird oft ohne Voraussetzungen zitiert. Sie war keine allgemeine Entschlüsselungsrate. Die Web-Konstruktion verlangte einen Angreifer im Pfad, beeinflussbare Anfragen, eine SSL-3.0-CBC-Sitzung und viele Wiederholungen. Allein die Serverunterstützung für SSL 3.0 verriet kein Cookie. Auch fiel nicht jeder Client bis dorthin zurück.

Die Abwehr hatte deshalb zwei verschiedene Aufgaben: SSL 3.0 aus dem Verkehr ziehen und, solange sofortige Entfernung an Altlasten scheiterte, verhindern, dass ein Angreifer die Notwendigkeit dieser Altlast vortäuschte.

TLS_FALLBACK_SCSV erledigte die zweite Aufgabe mit einem bewusst kleinen Signal. Der Wert {0x56,0x00} stand in der Cipher-Suite-Liste, war aber keine auswählbare Chiffre. Er bedeutete: Dieser ClientHello ist ein Rückfallversuch. Ein unterstützender Server verglich die angebotene Version mit seiner höchsten aktivierten Version. Konnte er mehr, beendete er die Verbindung mit dem fatalen Alarm 86, inappropriate_fallback.

Der Server brauchte weder einen zentralen Reputationsdienst noch ein Urteil über einen laufenden Angriff. Sein lokaler Versionszustand genügte für eine gemeinsame Konsequenz: eine unnötig niedrige Wiederholung zurückweisen. Darin verbinden sich eine minimale Regel und lokale Ablehnung.

Die Regel blieb absichtlich begrenzt. RFC 7507 weist darauf hin, dass gewöhnliche Netzstörungen ebenfalls Rückfälle auslösen können; der Alarm beweist keinen Angriff. SCSV ersetzt keine ordentliche Versionsaushandlung. Fehlt die Unterstützung an einem Ende, kann der alte Pfad bestehen bleiben. Unterstützt ein Endpunkt tatsächlich nur SSL 3.0, macht das Signal dieses Protokoll nicht sicher.

Das dauerhafte Urteil kam schrittweise. OpenSSL ergänzte SCSV in 1.0.1j, 1.0.0o und 0.9.8zc. RFC 7507 standardisierte das Signal im April 2015, RFC 7568 untersagte danach SSL 3.0. 2021 verwarf RFC 8996 TLS 1.0 und 1.1 und erklärte RFC 7507 für überholt, weil TLS 1.3 einen anderen Downgrade-Marker in ServerHello.Random verwendet.

Die Lehre lautet nicht, jede Übergangskontrolle auf Dauer zu erhalten. Kompatibilität darf aus einem mehrdeutigen Fehler keine stillschweigende Erlaubnis zur Schwächung machen. Ein enges Signal kann die Brücke sein, während unabhängige Systeme umstellen. Sobald die veraltete Kompatibilitätsmenge entfallen kann, muss auch die Brücke verschwinden.