Dipl.-Inform. Carsten Eilers

Die Protokolle Secure Sockets Layer (SSL) und sein Nachfolger Transport Layer Security (TLS), die auch zum Schutz von HTTPS-Verbindungen eingesetzt werden, verwenden X.509-Zertifikate, um die Identität ihrer Kommunikationspartner zu prüfen. Dazu enthalten z.B. die Webbrowser eine vorkonfigurierte Liste vertrauenswürdiger Zertifizierungsdienste (Certificate Authority, CA). Den von diesen CAs ausgestellten Zertifikaten vertrauen die Browser ohne weitere Prüfung, bei allen anderen Zertifikaten muss der Benutzer deren Nutzung erst erlauben. Die Zertifizierungsdienste sind in der Theorie alle vertrauenswürdig, in der Praxis kann man da bei einigen schon anderer Ansicht sein, aber das ist für das aktuelle Problem nicht wirklich von Belang.

Einer dieser Zertifizierungsdienste ist das Unternehmen Comodo, dass dazu gebracht wurde, gefälschte Zertifikate auszustellen. Der Tor-Entwickler Jacob Appelbaum hat am 22. März als erster auf das Problem hingewiesen: Er hat festgestellt, dass zuerst für Chromium und dann für Firefox zusätzliche Prüfungen der Zertifikate implementiert wurden. Beide Browser prüfen nun, ob die Seriennummern der Zertifikate auf einer internen Blacklist stehen. Allerdings blockieren Chrome und Firefox teilweise unterschiedliche Seriennummern.

Jacob Appelbaum überwachte daraufhin die Zertifikatssperrlisten (Certificate Revocation List, CRL), auf denen die Zertifizierungsdienste gesperrte Zertifikate veröffentlichen. Dabei fand er heraus, dass alle über die neuen Funktionen gesperrten Zertifikate von Comodo ausgegeben wurden.

Ebenfalls am 22. März veröffentlichten die Firefox-Entwickler einen recht nichtssagenden Eintrag im Mozilla Security Blog und machten darauf aufmerksam, dass Firefox nach einem Update mehrere gefälschte SSL-Zertifikate blockiert. Dass das zu wenig war und die Benutzer besser informiert werden müssen, hat man inzwischen eingesehen.

Mangelhafte Schutzmaßnahmen

In der Theorie ist die Public-Key-Infrastruktur der X.509-Zertifikate gut gegen solche Angriffe geschützt: Zurückgezogene Zertifikate werden auf den Zertifikatssperrlisten veröffentlicht und können über das Online Certificate Status Protocol (OCSP) online geprüft werden. In der Praxis lässt sich dieser Schutz unterlaufen, da sowohl die Abfrage der CRL als auch die Prüfung über das OCSP blockiert werden können, ohne dass die Browser in der Standardeinstellung eine Fehlermeldung ausgeben (siehe z.B. hier für die Reaktion auf "Verbindungsfehler" und "Defeating OCSP With The Character '3'" von Moxie Marlinspike (PDF) für einen Angriff auf das OCSP).

Neuen Versionen von Chrome (17. März) und Firefox (22. März) enthalten die zusätzliche Prüfung gegen eine interne Blacklist, Microsoft hat ein Update für Windows bereitgestellt, so dass die Zertifikate vom System erkannt werden, für Opera und Safari gibt es bisher kein Update. Erschwerend kommt hinzu, dass die Prüfung der Zertifikate in Mac OS X ausgeschaltet ist. Das lässt sich aber ändern: Im Programm "Schlüsselbundverwaltung" (im Ordner "Dienstprogramme") muss in den Einstellungen im Reiter "Zertifikate" für OCSP und CRL jeweils "Bester Versuch" und für Priorität "OCSP" ausgewählt werden, um die Prüfung der Zertifikate einzuschalten.

Was ist denn nun passiert?

Kommen wir zur wichtigsten Frage: Was ist da eigentlich passiert? Comodo hat inzwischen ein Stellungnahme und einen ausführlichen Bericht über den Vorfall veröffentlicht. Demnach wurde eine Registrierungsstelle (Registration Authority, RA), bei der die Zertifikate beantragt werden, erfolgreich angegriffen.

Eine RA prüft die Richtigkeit der Daten im gewünschten Zertifikat und genehmigt dann ggf. den Zertifikatsantrag, der dann durch den Zertifizierungsdienst signiert wird. In diesem Fall wurde ein Benutzerkonto der RA kompromittiert, der Angreifer konnte danach gefälschte Zertifizierungsanträge genehmigen, für die von Comodo dann zumindest zum Teil Zertifikate ausgestellt wurden.

Gefälschte Zertifikate wurden für folgende Namen beantragt und ausgestellt:

• login.live.com
• mail.google.com
• www.google.com
• login.yahoo.com (3 Zertifikate)
• login.skype.com
• addons.mozilla.org
• "Global Trustee" (wer oder was auch immer das ist)

Ob alle Zertifikate den Angreifer erreichten, ist nicht bekannt. Bisher wurde nur ein Teil der Zertifikate genutzt, und das auch nur in sehr geringem Umfang - jedenfalls, soweit es an OCSP-Abfragen erkennbar ist. Aber die könnten ja blockiert worden sein.

Was soll das ganze?

Was kann der Angreifer mit den gefälschten Zertifikaten anrichten? Nun, er kann seinen eigenen Server damit als den Server der oben aufgeführten Websites ausgeben. Dazu muss er aber die für diesen Server bestimmten Daten zu seinem Server umleiten oder sich als "Man in the Middle" zwischen Benutzer und richtigem Server befinden. Ein Benutzer kann dann nicht erkennen, dass er mit dem falschen Server verbunden ist, im Webbrowser wird eine korrekte, verschlüsselte Verbindung mit dem betreffenden Server signalisiert, da der ja das passende Zertifikat präsentiert hat.

Am nützlichsten ist so ein Zertifikat für einen Angreifer, der das DNS manipulieren kann, z.B. weil er als Staat seinen ISP entsprechende Vorschriften machen kann. Es liegt daher nahe, einen staatlichen Angriff zu vermuten. Da die Angriffe zu einer iranischen IP-Adresse zurückverfolgt wurden, liegt die Vermutung nahe, dass sie auch von der iranischen Regierung ausgelöst wurden. Oder von jemanden, der möchte, dass man die verdächtigt, denn woher der Angreifer wirklich kommt, kann man nicht mit Sicherheit feststellen. Die Information, dass Webhosting-Kunden aus dem Iran (und Syrien) kein SSL verwenden dürfen (via F-Secure), ist in der Hinsicht nicht hilfreich, da es ja nicht ums Hosting, sondern um die Nutzung durch Benutzer geht. Die entscheidende Frage wäre hier "Dürfen bzw. können Internet-Nutzer im Iran auf SSL-geschützte ausländische Websites zugreifen?". Falls das geht, könnte die iranische Regierung die gefälschten Zertifikate natürlich brauchen.

Worst Case

Mal angenommen, der Angriff erfolgte im Auftrag der iranischen Regierung. Die könnte dann die ISPs im Lande zwingen, Anfragen an die aufgeführten Domainnamen auf einen staatlichen Server umzuleiten, der sich dann mit den erbeuteten Zertifikaten als "richtiger" Server ausgibt. Die Behörden können dann die übertragenen Daten belauschen und manipulieren.

Dann muss natürlich auch die Nutzung von CRL und OCSP verhindert werden, sonst würden ja die gefälschten Zertifikate u.U. auffallen. Denn der Angreifer weiß ja, dass sein Angriff bemerkt wurde, da sein Zugang gesperrt wurde. Die Firefox-Entwickler haben ihre Informationen über den Angriff nicht früher veröffentlicht, weil sie Angst hatten, die Angreifer würden dann die Updates blockieren. Gute Idee, aber vermutlich falsch. Wer sich so viel Mühe macht, wird auch damit rechnen, dass die Browser-Hersteller reagieren und die Updates blockieren oder manipulieren.

Und nun?

Der Vorfall zeigt einige Probleme auf, die behoben werden müssen. Zuerst einmal würde es helfen, wenn die Programme (alle, nicht nur die Webbrowser!) bei einem Fehler in der Zertifikatsprüfung das betroffene Zertifikat zurückweisen. Wenn die CRL nicht geladen werden kann oder OCSP nicht funktioniert, darf dem Zertifikat nicht vertraut werden. Die hardcodierte Blacklist in den Browsern ist nur ein schlechter Workaround. Wie gross soll die werden? Und wie schnell wollen die Hersteller Updates veröffentlichen?

Dann muss das bisherige Geschäftsmodell der Zertifizierungsdienste geprüft werden. Wer mehrmals negativ auffällt, gehört eigentlich aus den Voreinstellungen der Programme rausgeschmissen. Einem Zertifizierungsdienst muss man zu 100% vertrauen können - es gibt keine Abstufungen wie "Dem vertraue ich nur bei unwichtigeren Websites" o.Ä.. Gibt es Zweifel an der Vertrauenswürdigkeit und/oder Zuverlässigkeit, kann man einen Anbieter nur komplett sperren.
Zu Comodo gibt es mehrere Einträge im Mozilla-Bugtracker, Konsequenzen hat das nicht. Was verständlich ist, denn wenn die Zertifikate eines Zertifizierungsdiensts nicht mehr akzeptiert werden, ist erst mal der Browserhersteller der Böse, zumindest, wenn andere Browser die Zertifikate weiterhin akzeptieren. Denn betroffen sind ja in erster Linie die harmlosen Websites, die Zertifikate des Anbieters nutzen, sowie deren Benutzer. Die kommen dann plötzlich nicht mehr auf ihre Websites, und dass nur, weil der Browser spinnt. Verständlich, dass die Browserhersteller es darauf nicht ankommen lassen.

Und zu guter Letzt stellt sich die Frage "Wem vertrauen wir eigentlich - und wieso?" Wir vertrauen den Zertifikaten, die vom Browser (oder jedem anderen Programm) akzeptiert werden. Kaum jemand hinterfragt dieses Konzept. Eigentlich ist das ein ziemlich riskanter Ansatz, wenn man bedenkt, dass man darauf sein Onlinebanking und seine sichere Kommunikation aufbaut.
Im Grunde müsste man jeden Zertifizierungsdienst persönlich prüfen, denn ob man jemanden vertraut oder nicht, muss man ja wohl letztendlich selbst entscheiden und kann diese Entscheidung nicht Dritten überlassen. Zur Zeit vertrauen wir darauf, dass die Programmhersteller den vertrauenswürdigen Zertifizierungsdiensten vertrauen. Aber wenn ich mir die Liste der von Mozilla für vertrauenswürdig gehaltenen Zertifizierungsdienste ansehe habe ich doch gewisse Zweifel, ob die alle meinen Ansprüchen genügen. Warum sollte ich einem Zertifizierungsdienst aus z.B. China unbesehen vertrauen? Es reicht doch, wenn ich denen vertraue, von denen ich (bzw. genauer: Die von mir benutzten Websites etc.) Zertifikate verwende. Alle anderen stellen ein unnötiges Risiko dar.

Außerdem wäre sicher auch hilfreich, wenn man wüsste, wer dieser ominöse "Global Trustee" ist, für den ein Zertifikat ausgestellt wurde. Das ist doch hoffentlich nicht die Domain eines Zertifizierungsdienstes? Irgendwie fürchte ich ja fast, dass doch... Hat Comodo etwa ein Zertifikat für eine Domain eines Konkurrenten signiert?

Warum denn nun "Super-GAU"?

Wäre es ein Unfall, wäre es ein Super-GAU, da die vorhandenen Schutzmaßnahmen nicht ausreichen und die Browser-Entwickler aushelfen mussten. Übrigens betrifft das Problem nicht nur die Browser, sondern alles, was über SSL/TLS abgesichert wird. Microsoft hat es entsprechend auch allgemein und nicht nur im Internet Explorer behoben, und Jacob Appelbaum hat ein Update für den Tor Browser angekündigt. Auch für andere Programme wären jetzt Updates fällig.

Carsten Eilers