Schwachstelle im SSL/TLS-Protokoll

Schwachstellen im SSL/TLS-Protokoll lassen sich Berichten zufolge von Angreifern ausnutzen, um in geschützte Verbindungen eigene Inhalte einzuschleusen. Betroffen wären neben HTTPS auch alle anderen Protokolle wie IMAP, die zur Transportsicherung TLS einsetzen. Über die genauen Auswirkungen des Problems wird noch diskutiert. Möglich wäre aber offenbar, etwa HTML-Inhalte von Webseiten während der Übertragung zu manipulieren und beispielsweise Schadcode zu injizieren.

Knackpunkt der Probleme ist statt eines Implementierungsfehlers ein Designfehler im TLS-Protokoll bei der Neuaushandlung der Parameter einer bestehenden TLS-Verbindung (TLS Renegotiation). Diese findet beispielsweise statt, wenn ein Client auf einem Webserver auf einen geschützten Bereich zugreifen will und der Server ein SSL-Client-Zertifikat zur Authentifizierung anfordert. Allerdings sieht das Protokoll offenbar keine eindeutig authentifizierte Zuordnung eines Client-Requests auf eine bestimmte URL zu dem anschließend ausgelieferten Client-Zertifikat vor – der Server nimmt es einfach als korrekt an. Die Entdecker der Probleme sprechen daher in diesem Zusammenhang von einem "Authentication Gap".

Ein Angriff könnten laut Bericht etwa so funktionieren: Ein Angreifer schleift sich in die Verbindung zwischen Client und Server ein und baut mit dem Server eine HTTPS-Verbindung auf. Die Verbindung zum Client hält er zunächst kurzfristig in einem unvollendeten Zustand. Anschließend schickt er an den Server einen HTTPS-Request auf einen geschützten Bereich, der daraufhin eine Neuaushandlung für eine völlig neue Verbindung startet und das Client-Zertifikat anfordert. Alle folgenden Pakete leitet der Angreifer nun unverändert zwischen Server und Client weiter. Abschließend wird der HTTP-Request des Angreifers im Kontext des Clients ausgeführt, beispielsweise ein POST-Request für ein geschütztes Formular.

Konkret wurden die Probleme auf aktuellen Versionen der Webserver von Microsoft IIS und der Apache Foundation httpd nachvollzogen. Daneben ist auch OpenSSL betroffen. Ben Laurie hat bereits einen Patch entwickelt, der aber das eigentliche Problem nicht beseitigt, sondern nur nur die Neuaushandlungen verhindert. Über eine nachhaltige Lösung wird diskutiert. Möglich wäre ein frühzeitiges Ausliefern von Client-Zertifikaten noch vor dem Anfordern einer konkreten URL. Nebenbei soll die TLS Channel Bindings Working Group der IETF an einem Draft arbeiten. Möglicherweise gibt es daher schon eine Lösung.

Siehe dazu auch:

• Authentication Gap in TLS Renegotiation, Bericht von Marsh Ray
• Another Protocol Bites The Dust, Bericht von Ben Laurie
• MITM attack on delayed TLS-client auth through renegotiation, Bericht von Martin Rex