Erstmal hoffe ich, dass alle meine LEser gut in’s neue Jahr 1984v2 gekommen sind und man sich nun nach den etwas stressigen letzten Tagen des alten Jahres gut erholt hat. Aber halt! Da war ja der 25C3 mit einer ganzen Reihe interessanter Vorträge zum Thema Sicherheit, u.a. in Bezug auf verschiedene Protokolle wie DNS und TCP, aber auch in Bezug auf eine ganze Reihe neuer Angriffe, die wie eigentlich in jedem Jahr, auf dem Kongress vorgestellt wurden, darunter Cold Boot Attacks gegen den Speicher frisch ausgeschalteter Computer, Angriffe gegen Web Services, aber auch Angriffe gegen verschlüsselte PHP-Anwendungen.
Nein, ich möchte jetzt nicht den gesamten Kongress im Detail wiedergeben – zu dem ich ohnehin aus verschiedenen Gründen leider nicht fahren konnte: ich möchtee eher ein anderes Problem hervorheben, wo der Kongress einmal mehr überaus deutlich gezeigt hat, dass ein Umdenken und eine alternative Lösung mehr als notwendig ist, da die vorhandenen Mittel auf lange Sicht nicht weiter vor einer Katastrophe schützen können, wie der Vortrag zu SSL und der Erstellung eines gültig-unterschriebenen CA-Zertifikates gezeigt haben.
SSL ist eine Abkürzung für Secure Socket Layer und dient im Normalfall dazu, eine Transport-Verschlüsslung von Datenströmen, in erster Linie aber eine Authentifizierung der Gesprächspartner zu ermöglichen. Während die Transport-Verschlüsslung das mit am häufigsten genutzte Feature der meisten SSL-Bibliotheken sein dürfte, wird die Authentifizierung von Gesprächspartnern oftmals nur Stiefmütterlich bis gar nicht genutzt. So war in mehreren Vorträgen wiederholt zu hören, dass eine ganze Reihe von Anwendungen die via SSL vorgenommene Authentifizierung nur unzureichend bis gar nicht überprüft: Bei manchen Programmen (darunter einige IRC-Clients) soll es bereits reichen, überhaupt SSL zu sprechen. Das ist weit von dem entfernt, wozu SSL gedacht ist.
Der Einsatzzweck von SSL ist primär, eine Platform für vertrauenswürdige Authentifizierung von Diensten zu ermöglichen. Das hierfür vorgesehene Konzept sieht dabei die Nutzung sogenannter Certification Chains vor, die ausgehend von einer Root-CA einen eindeutigen Vertrauenspfad für einen Dienst bereitstellen. Hierbei steht an erster Stelle eine Certification Authority wie VeriSign oder CAcert, die einem Antragsteller seine Identität beglaubigt und somit für die Richtigkeit der von ihr zertifizierten Dienste birgt. Und genau hier haben manche Anbieter über Jahre hinweg geschlampt, denn wie sonst ist es zu erklären, dass Comondo mal eben ohne Nachfrage *.com zertifiziert. Das Vertrauen in CAs ist somit schon einmal futsch – genauso wie die Berechtigung von Comondo, in meinem Browser irgendetwas als sicher zu zertifizieren.
Aber gut, wenn die CAs schon nicht vertrauenswürdig sind, dann doch aber wenigstens die Zertifikate? Weit gefehlt, denn auch hier hat sich inzwischen einiges getan. Bereits seit 2004 war bekannt, dass MD5 wahrscheinlich nicht sicher ist, was aber bis vor kurzem scheinbar keine Zertifizierungsstelle ernsthaft beunruhig zu haben scheint, da immer noch ein Großteil der Zertifikate mit MD5 ausgestellt werden.
Dies ist insbesondere dann verwunderlich, wenn bereits 2006 und darauf aufbauend 2007 weitere Attacken vorgestellt wurden, die gezeigt haben, dass ein Angriff auf einen MD5-Hash praktisch durchführbar ist – es bedurfte aber der auf dem Kongress vorgestellten Demonstration, um auch endlich Bewegung in die Geschichte zu bringen.
Und wer jetzt denkt, dass er sich einen Gefallen tut, wenn er auf eine Zertifizierungsstelle ganz verzichtet und stattdessen Self-Signed seine Zertifikate verteilt, der schafft insbesondere bei aktuellen Browsern wie dem Firefox 3 ein Übel, welches er gerade bekämpfen wollte. Ich hasse Self-Signed Zertifikate und jede Seite, die solche nutzt, darf mich auch zukünftig nicht als Besucher erwarten – gerade nicht, wenn self-signed genommen wird „weil es egal ist, ob man ein CA-Zertifikat oder eine eigene Root im Browser importiert“. Danke, aber auf diesen Webmaster kann ich gern verzichten!
Aber auch die Browser sind an vielen Stellen nicht besser. Gerade, wenn es um Sicherheit geht. Hier hat der Firefox einfach noch nachholbedarf, was nicht nur ich, sondern auch andere so sehen. So fehlt dem Firefox eine Möglichkeit, den User zu warnen, wenn sich das SSL-Zertifikat einer Website geändert hat, obwohl dieses weder abgelaufen, noch zurückgezogen wurde. Dieser Schutz ist zwar False-Positive-behaftet, jedoch kann er, bei richtiger Implementierung dem User eine gute Unterstützung beim Erkennen von Man-in-the-Middle-Angriffen bieten.
Aber es muss ja nicht immer ganz so Hightech sein. Firefox bietet bereits seit der 2er Version die Möglichkeit, in der Adressbar nicht nur die grüne Bestätigung bei Class 3-Zertifikaten anzuzeigen, sondern auch bei Class 1-Zertifikaten die Identität darzustellen. Was gut gemeint ist, wurde aber sinnfrei implementiert, so dass auch bei unterschiedlichen Zertifikaten das gleiche Zertifizierungsobjekt angezeigt werden, was einem Angreifer nützt, um bestimmte Angriffe einfacher zu verschleiern.
Firefox ist da aber auch für eine ganze Reihe anderer Fehler bekannt. Wenn also mal nicht die GUI defekt ist, so ist’s die API. Was will man machen???
Somit bleibt eigentlich, den Vortragenden folgend, festzustellen:
The Internet is broken!
