SSL/TLS

Felix von Leitner schreibt in seinem Blog über eine wirklich gefährliche Angriffsmöglichkeit, die sich aus dem OpenSSL-Debakel ergibt. Alle Verbindungen zu Servern, die ein "schlechtes" SSL-Zertifikat hatten, sind wahrscheinlich immer noch verwundbar. Felix berichtet, dass dies bei einem Server von Akamai der Fall ist, und über Akamai werden Daten für das Steuerprogramm ELSTER übermittelt.

Wie es funktioniert

Die Angreiferin, nennen wir sie Carol, ruft Daten von einer Webseite ab, deren URL mit https beginnt, also über eine SSL-verschlüsselte Verbindung — z.B. beim Online-Banking. Sie erhält dabei das Zertifikat der Webservers, welches sie speichert. Dieses Zertifikat und der geheime Schlüssel dazu sind nun aber mit der kaputten Version von OpenSSL erzeugt worden.

Mit dem Zertifikat und dem enthaltenen öffentlichen Schlüssel alleine kann Carol nichts anfangen, es ist ganz normal, dass man diese übermittelt bekommt. Wichtig ist allerdings, dass das Zertifikat von einer Zertifikatsautorität (CA) signiert wurde, wodurch die Echtheit sozusagen "offiziell" beglaubigt ist.

Der geheime Schlüssel ist außerdem dank des OpenSSL-Fehlers leicht ermittelbar — Carol erzeugt alle möglichen geheimen Schlüssel einfach selbst und prüft, welcher zu dem öffentlichen Schlüssel des Servers passt.

Nun hat Carol also sowohl den geheimen Schlüssel, den eigentlich nur der Server kennen sollte, als auch ein "von offizieller Stelle" signiertes Zertifikat.

Die Zertifikate der "offiziellen Stellen", also der CAs sind in jedem Webrowser vorinstalliert, das heißt jeder Webbrowser erkennt auch das Zertifikat ohne weitere Prüfung oder Abfrage als gültig an, obwohl es unsicher ist:



Natürlich haben die Betreiber die verwundbaren Zertifikate schon ausgetauscht. Aber Carol war schnell, und hat das alte vorher gespeichert, gleich nachdem der OpenSSL-Fehler bekannt wurde. (Zukünftig wird Carol dies automatisieren, ein kleines Programm speichert die Zertifikate während sie im Web surft. Denn vielleicht gibt es nochmal so einen Fehler.)

Zwar überprüft ein Browser das Ablaufdatum, welches unveränderlich im Zertifikat steht und dieses nach einer bestimmten Zeit automatisch ungültig macht, aber das ist schlichtweg noch nicht erreicht.

Dagegen gibt es natürlich auch einen Schutzmechanismus, nämlich zentrale Stellen, die Listen mit vorzeitig für ungültig erklärten Zertifikaten enthalten, sogenannte CRLs (Certificate Revocation Lists). Doch diese Listen muss der Browser auch abrufen.

Tut er aber nicht:



Die Standard-Einstellung des Browsers Firefox ist, keine CRLs abzurufen. Das dürfte bei vielen Programmen so sein, und auch E-Mail-Programme, Homebanking-Programme und Programme zur Übermittlung der Steuererklärung benutzen SSL.

Schaltet man die Prüfung ein, so funktioniert sie möglicherweise nicht, was die Funktion einfach nur lästig macht:



Mit dem privaten Schlüssel und dem signierten Zertifikat kann Carol nun dem Browser irgendeines Users glaubhaft vormachen, ihr eigener (manipulierter) Server sei der Server, dessen Zertifikat sie "übernommen" hat. Sie kann sich also als Mittelsmannfrau in die vermeintlich geschützte Verbindung einklinken, und somit Daten mitlesen, unterdrücken oder gar verändern, also zum Beispiel Schadcode, etwa einen Trojaner, einschleusen.

Man nennt dies eine Man-In-The-Middle-Attacke, kurz MITM. (Oder WITM. Wegen der Gleichberechtigung.)

Der Haken beim PKI-Verfahren

Wie Felix ganz richtig schreibt, ist das ganze Prinzip der PKI, der Echtheitsprüfung durch irgendwelche Zentralstellen, die der User gar nicht kennt, ihnen also auch nicht vertrauen kann, schon allein durch die Zahl der standardmäßig installierten CA-Zertifikate der eigenartigsten CAs höchst zweifelhaft.

Es ist keine Diskriminierung, sondern reine Vernunft, wenn ich sage, dass ich eigentlich nicht möchte, dass die mir völlig unbekannte Stelle "TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş" (Türkei) oder die"NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado" (Ungarn) Zertifikate für gültig erklärt, mit denen mein Browser verschlüsselte, also vermeintlich sichere Verbindungen aufbaut.

Ich muss überhaupt nicht an Geheimdienste denken, ganz normale Kriminelle werden schon ihre Wege finden, die ein oder andere CA für ihre Zwecke zu missbrauchen.

Was tun?

Das einzige, was Server-Betreiber gegen diesen Angriff tun können, ist das alte Zertifikat dadurch unbrauchbar zu machen, dass sie ihre Domain ändern, bis die alten Zertifikate abgelaufen sind. Dumme Sache.

Benutzer müssen bei vielen Webseiten, die keine "offiziell beglaubigten" Zertifikate haben, ohnehin selbst entscheiden, ob sie das Server-Zertifikat

• nur temporär akzeptieren (es könnte gefälscht sein)
• dauerhaft akzeptieren (sie kommunizieren zumindest immer mit dem selben Server und halten es für unwahrscheinlich, dass Carol dahinter steckt) oder
• verifizieren.

Um diese Entscheidung immer selbst zu fällen, können sie alle CAs, denen sie nicht vertrauen — das werden wohl nahezu alle sein — in den Einstellungen ihrer Software deaktivieren.

Wenn es wichtig ist, und sie das Zertifikat verifizieren müssen, — die Fingerprints überprüfen, in dem sie den Betreiber anrufen.

Bei so etwas wichtigem wie dem Online-Banking oder der Steuerrerklärung z.B. sollte man das unbedingt tun!

Banken und Behörden werden sich natürlich wundern, aber es ist deren Schuld, schließlich schicken die den Kunden zwar stapelweise Papier mit PINs, TANs und iTANs, aber die Fingerprints ihrer Banking-Webseiten und Steuerdatenserver fehlen in den Unterlagen.