Fehler potenziert

Das Interessante hierbei: Eigentlich sollte ein solcher Angriff selbst mit der unsicheren MD5-Funktion überhaupt nicht möglich sein. Denn SSL-Zertifizierungsstellen fügen in das Zertifikat eine zufällig erzeugte Seriennummer ein. Für den erfolgreichen Angriff war es aber nötig, zwei Zertifikate mit identischem MD5-Hash zu erzeugen, die Angreifer mussten also vorher exakt wissen, welche Daten in das Zertifikat eingetragen werden. Doch sie fanden einen Fehler bei der Zertifizierungsstelle RapidSSL: Diese fügte keine zufällige Seriennummer ein, sondern eine inkrementell erhöhte. Da die Zertifikate relativ günstig waren, konnten die Angreifer eine wahrscheinliche Seriennummer raten und nach mehreren Versuchen gelang ihnen der Angriff.

Ein Angriff auf MD5 mit ganz praktischen Auswirkungen wurde dann 2012 bekannt: Der Virus Flame enthielt eine gültige Code-Signatur von Microsoft [6] und konnte sich so über den Windows-Update-Service verbreiten. Die genauen Details der Attacke sind unbekannt, doch Kryptografen gehen davon aus, dass die Programmierer von Flame Wissen über weitere Schwächen von MD5 haben, die bisher nicht öffentlich bekannt sind.

Umstellung auf SHA-2 schleppend

Im Jahr 2011 waren noch nahezu alle SSL-Zertifikate mit einer SHA-1-Signatur versehen ( Abbildung 1 ). Erst im Jahr 2012 fingen erste Zertifizierungsstellen mit dem Wechsel auf SHA-2 an. Das Problem hierbei: die Abwärtskompatibilität. Fragte man bei den Zertifizierungsstellen nach, so erhielt man die Antwort, dass das nach wie vor häufig genutzte Windows XP vor dem Service Pack 3 keine SHA-2-Signaturen unterstützt. Derartige Kompatibilitätsprobleme dürften in Zukunft eher noch zunehmen. Wer will schon von seinem Webservice für einen geringen Sicherheitsgewinn etwa die Nutzer alter Smartphones ausschließen?

Abbildung 1: Heute noch absoluter Normalfall: Zertifikat enthält SHA-1-Signatur.

Noch schwieriger sieht die Situation bei den Übertragungsprotokollen aus. Der alte, nach wie vor häufig genutzte SSL-Standard in der Version 3 unterstützt nur MD5- und SHA-1-Signaturen. Auch die Nachfolger TLS 1.0 und 1.1 bringen keine Besserung, erst mit TLS 1.2 werden neuere Algorithmen mit SHA-2 unterstützt. Auf der Serverseite wird für die Aktivierung von TLS 1.2, etwa im Apache-Webserver, die Version 1.0.1 von OpenSSL benötigt. Doch bisher unterstützt einzig der Opera-Browser TLS 1.2. Somit können Serveradministratoren zwar den neuen, sichereren Standard aktivieren, genutzt wird er aber vermutlich kaum. Und die Abschaltung der alten Algorithmen dürfte für die lange Zeit nicht infrage kommen. Die Abschaltung von MD5-Signaturen ist aber schon heute bedenkenlos möglich und empfehlenswert.

Aktiviert werden kann TLS 1.2 – OpenSSL 1.0.1 und eine aktuelle 2.2 oder 2.4-Version des Apache-Webservers vorausgesetzt – mit der Konfigurationsoption »SSLProtocol« . Eine mögliche Serverkonfiguration könnte wie in Listing 1 aussehen.

Mit hoher Wahrscheinlichkeit bestehen heute noch keinerlei Sicherheitsprobleme, wenn man SHA-1 verwendet. Doch die Erfahrung mit MD5 lehrt, dass die Umstellung weg von schwachen Algorithmen sehr lange dauert. Trotz der seit 1996 bekannten Probleme konnte der Flame-Virus noch 2012 – ganze 18 Jahre später – erfolgreich die MD5-Signaturen des Windows-Update-Service angreifen.