Skip to content

Falsche Zertifikate für Google und andere - ist SSL tot?

Aus aktuellem Anlass heute ein anderes als das angekündigte Thema:
Der niederländische Zertifizierungs-Dienstleister (Certificate Authority, CA) DigiNotar hat SSL- und Extended Validation SSL (EVSSL)- Zertifikate für mehrere Domains ausgestellt, die nicht vom eigentlichen Domain-Inhaber beantragt wurden. Darunter am 10. Juli eins für alle google.com-Domains (*.google.com), das damit sieben und nicht wie oft behauptet fünf Wochen (die 28. bis 34.) unentdeckt blieb, bis es am 28. August entdeckt und am 29. August zurückgezogen wurde. Herausgekommen ist der Vorfall, als Man-in-the-Middle-Angriffe, insbesondere auf Nutzer von Google Mail, bekannt wurden. Es wird vermutet, dass sich die iranische Regierung das Zertifikat beschaffte, um die iranische Bevölkerung auszuspähen.

Verkauft oder gestohlen?

Während es anfangs hieß, das gefälschte Google-Zertifikat wäre regulär bei DigiNotar gekauft worden (niederländischer Artikel, englische Microsoft-Translator-Übersetzung, die deutsche ist leider völlig unbrauchbar), erklärte das Unternehmen später, es sei Opfer eines Angriffs geworden. Diese Erklärung wirft aber mehr Fragen auf als sie beantwortet.

Demnach wurde am 19. Juli ein Angriff auf die CA erkannt, die von den Angreifern ausgestellten Zertifikate zurückgerufen und ein externer Sicherheits-Audit eingeleitet. Hier ist erst mal festzustellen, dass das Google-Zertifikat am 10. Juli ausgestellt wurde (s.o.), die Angreifer also mindestens 9 Tage unbemerkt die Kontrolle über die angegriffenen Systeme hatten. Wie viele gefälschte Zertifikate ausgestellt wurden und für welche Domains sie gelten, wurde bisher verschwiegen. Google hat in Chromium 247 Zertifikate neu gesperrt, wie viele prominente Domains betroffen sind kann man nur raten. Laut The Register befinden sich darunter addons.mozilla.org, Yahoo.com, das Tor Project, WordPress und der iranische Blog-Anbieter Baladin. Während im Fall von addons.mozilla.org der Firefox-Chefentwickler zitiert wird, gibt es für die anderen Angaben keine verlässliche Quelleninformation.

Der externe Audit ergab, das alle betroffenen Zertifikate zurückgezogen wurden. Trotzdem wurde (mindestens) ein Zertifikat übersehen, ausgerechnet das für *.google.com. Mal abgesehen davon, dass der externe Audit vollkommen versagt hat stellt sich die Frage, wieso niemandem aufgefallen ist, dass man ein Zertifikat für Google ausgestellt hat. Oder warum sich niemand darüber gewundert hat, dass Google sich ein Zertifikat bei einer kleinen niederländischen CA holt und nicht wie zuvor bei Thawte.

Desweiteren stellt sich die Frage, wieso keine Warnung vor den falschen Zertifikaten veröffentlicht wurde. Sollte man in den Niederlanden nichts vom Angriff auf die CA von Comodo und deren Folgen gehört haben?

Nach dem Audit sollte ja eigentlich alles in Ordnung sein. Sollte man meinen. Dem ist aber ganz und gar nicht so, denn wie F-Secure herausfand, haben ein paar Hacker auf der Website von DigiNotar ihre Visitenkarten hinterlassen. Nun haben Webserver und CA-Infrastruktur (hoffentlich) nichts miteinander zu tun, aber wenn ein Angreifer 9 Tage sein Unwesen auf einem System getrieben hat, ist man gut beraten, dass und alle damit verbundenen Systeme sehr genau zu prüfen. Das ist anscheinend unterblieben. Denn die Defacement-Spuren sind "uralt", u.a. aus dem Mai 2009.

Und dann hat DigiNotar noch einen Artikel in niederländisch (englische Microsoft-Translator-Übersetzung) veröffentlicht, in dem erklärt wird, dass 99,99% der Browser-Warnungen vor ihren Zertifikaten ignoriert werden können. Einen gefährlicheren Rat kann man wohl kaum geben. Hätte man die Liste der gefälschten Zertifikate veröffentlicht und erklärt, bei allen anderen bestünde keine Gefahr, wäre das durchaus akzeptabel. So stellt sich die Frage, woran man die 0,01% echten Warnungen erkennt.

Update:
Vom Tor Project wurde bestätigt, dass gefälschte Zertifikate für deren Server erstellt wurden.
Swa Frantzen hat im ISC Diary den bisher gekannten Zeitablauf zusammen gestellt.
Update Ende

Trau, schau wem!

Fassen wir mal zusammen:

  1. Die CA wurde erfolgreich angegriffen
  2. Der Angriff wurde erst nach mindestens 9 Tagen entdeckt
  3. Es wurden mehrere gefälschte Zertifikate ausgestellt, darunter mindestens ein Extended-Validation-Zertifikat, dessen Ausgabe an besonders strenge Vergabekriterien gebunden ist - zumindest letzteres darf einer CA nicht passieren
  4. Alle Zertifikate wurden zurückgezogen, dabei aber (mindestens) eins übersehen
  5. Es wurde keine Warnung vor den gefälschten Zertifikaten veröffentlicht, obwohl einer CA bekannt sein muss, dass der Zertifikatsrückruf nicht unbedingt sicher ist und viele Browser die Rückruflisten nicht per Default überwachen
  6. Ein externer Audit stellt fest, dass alle gefälschten Zertifikate zurückgerufen wurden (was man nicht der CA anlasten kann, der kann man höchstens vorwerfen, den falschen Dienstleister gewählt zu haben)
  7. Ein übersehenes Zertifikat wird entdeckt, erst jetzt entschließt man sich zu einer Presseerklärung
  8. Nach dem Audit finden sich noch Spuren von Hackern auf der Website der CA
  9. Die CA gibt den Rat, die Benutzer sollten die Warnungen vor den Zertifikaten in den allermeisten Fällen ignorieren.

Die Frage nach der Vertrauenswürdigkeit so einer CA braucht man wohl nicht mehr zu stellen. Bis auf weiteres will DigiNotar keine Zertifikate mehr ausstellen, aber wer sollte auch Interesse dran haben? Von den meisten Browsern wird denen sowieso kein Vertrauen mehr entgegen gebracht, und im Zweifelsfalls ist eine Website ohne Zertifikat wohl vertrauenswürdiger als eine, die ein Zertifikat einer nicht vertrauenswürdigen CA vorweist.

Die Reaktionen

Eigentlich ist es ganz einfach, das Problem zu lösen: Wenn Sie das Root-Zertifikat einer unerwünschten CA aus ihrem System bzw. Browser löschen oder ihm das Vertrauen entziehen, werden danach alle von dieser CA ausgestellten Zertifikate als unbekannt bzw. ungültig erkannt und entsprechend gemeldet. Wobei im Fall einer Kompromittierung dem Zertifikat besser das Vertrauen entzogen werden sollte, da das ja den Tatsachen entspricht. Beim Löschen des Zertifikats besteht bei der späteren Meldung "Das Zertifikat konnte nicht geprüft werden, da die CA unbekannt ist" die Gefahr, dass dem Zertifikat irrtümlich doch vertraut wird. Bei der Warnung, dass es nicht vertrauenswürdig ist, ist diese Gefahr deutlich geringer.

In diesem Fall muss also nur dem Root-Zertifikat von DigiNotar das Vertrauen entzogen werden, um jede Gefahr zu beseitigen. Wie das in Firefox funktioniert, wird in der Online-Hilfe beschrieben. Prinzipiell funktioniert das bei allen Browsern und Systemen ähnlich. Es gibt aber auch Sonderfälle. So suchen Benutzer von Safari unter Mac OS X eine entsprechende Einstellung in ihrem Browser vergeblich. Safari nutzt die Zertifikatsverwaltung des Systems, die Konfiguration wird in der Schlüsselbundverwaltung, zu finden bei den Dienstprogrammen, erledigt, wie hier von Coriolis beschrieben. Dort wird empfohlen, das Zertifikat nicht nur zu sperren, sondern zu löschen, da Safari sonst eine irreführende Warnung ausgibt. Wenn sie sowieso gerade die Schlüsselbundverwaltung offen haben, sollten sie in den Einstellungen unter "Zertifikate" gleich noch die Einstellungen für deren Prüfung kontrollieren. Sowohl für OCSP als auch für CRL sollte "Bester Versuch" ausgewählt sein, die Priorität sollte auf OCSP gestellt werden.

Einige Hersteller haben bereits Maßnahmen ergriffen, um Ihnen das manuelle Ändern der Zertifikate zu ersparen. Von Mozilla gibt es Updates für Firefox für Windows, Mac OS X und Linux, SeaMonkey und Thunderbird, in denen dem DigiNotar Root-Zertifikat das Vertrauen entzogen wurde. Und auch Google hat eine neue Version von Chrome für Windows, Mac OS X und Linux veröffentlicht, in der DigiNotar deaktiviert wurde. Bei Opera dagegen verfolgt man einen anderen Ansatz, der auf der Certificate Revocation List basiert. Ist die nicht erreichbar, wird die Seite als normale Seite gekennzeichnet. Das ist zwar besser als nichts, eine Warnung erfolgt aber nicht.

Microsoft hat ein Security Advisory veröffentlicht. Windows-Versionen ab Vista verwenden die Microsoft Certificate Trust List, über die dem DigiNotar Root-Zertifikat Systemweit das Vertrauen entzogen wurde. Es gibt also auch eine Warnung, wenn z.B. versucht wird, ein mit einem DigiNotar-Zertifikat signiertes Programm zu installieren. Für Windows XP und Windows Server 2003 ist ein Update notwendig, das noch nicht zur Verfügung steht.

Ist SSL tot?

Nach dem Angriff auf Comodo im März ist dies der zweite erfolgreiche Angriff auf eine CA in kurzer Zeit, bei der gefälschte Zertifikate "erbeutet" wurden, und auch davor wurden schon falsche Zertifikate ausgestellt. Muss man SSL also misstrauen? Die Antwort lautet "Jein": SSL funktioniert aus technischer Sicht einwandfrei, die verschlüsselt übertragenen Daten sind sicher. Das Problem ist das Zertifizierungssystem. Es gibt zu viele Zertifizierungsstellen, denen die Webbrowser und Systeme "von Haus aus" vertrauen. Dieses Vertrauen ist vielleicht in den meisten Fällen gerechtfertigt, aber es wird grundlos auf alle und damit auch auf die schwarzen Schafe ausgedehnt. Über mögliche Alternativen wird bereits nachgedacht, mehr dazu in der nächsten Folge.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Vertrauensfragen

Vorschau anzeigen
Der aktuelle Angriff auf bzw. die Reaktion darauf durch DigiNotar macht ein grundlegendes Problem der IT-Sicherheit, nicht nur im Umgang mit SSL-Zertifikaten, sichtbar: Vertrauen, das missbraucht werden oder ungerechtfertigt sein kann. Oder beid

Dipl.-Inform. Carsten Eilers am : Der Angriff auf DigiNotar und seine Folgen

Vorschau anzeigen
Der Angriff auf die niederländische CA DigiNotar zieht immer weitere Kreise. Welche, erfahren Sie hier. Die angekündigte Beschreibung einer Alternative zum bestehenden Zertifizierungssystem verschiebt sich daher um eine Woche. Mind

Dipl.-Inform. Carsten Eilers am : Alternativen zum SSL-CA-Zertifizierungssystem

Vorschau anzeigen
Spätestens seit dem Angriff auf DigiNotar und seinen Folgen dürfte jedem klar geworden sein, dass das bestehende Zertifizierungssystem für SSL-Zertifikate unsicher ist und eine permanente Bedrohung darstellt. Wenn man den Zertifizi

Dipl.-Inform. Carsten Eilers am : Das RAT, das aus dem Stuxnet kam

Vorschau anzeigen
Mehrere Antiviren-Hersteller haben einen neuen Schädling entdeckt, der teilweise als Stuxnet-Ableger bezeichnet wird. Da ist aber zumindest etwas irreführend. Der Duqu genannte neue Schädling weist einige Parallelen zu Stuxnet auf,

Dipl.-Inform. Carsten Eilers am : Neues zu SSL und Duqu

Vorschau anzeigen
Sowohl zu SSL/TLS als auch zu Duqu gibt es Neues zu berichten. Wobei es sich streng genommen im Fall von SSL lediglich um Bestätigungen eigentlich bereits bekannter Behauptungen und Tatsachen handelt. SSL: Weitere Zertifizierungsstellen kom

Dipl.-Inform. Carsten Eilers am : Apple geg. Kaspersky, Angreifer geg. PHP, Irgendwer geg. den Iran, und mehr

Vorschau anzeigen
Heute gibt es mal wieder eine bunte Mischung an Kommentaren: Apple erlaubt keine Virenscanner im App-Store, es gibt Angriffe auf die PHP-CGI-Schwachstelle, Yahoo! veröffentlicht einen privaten Schlüssel, eine Verbesserung für TLS soll

Dipl.-Inform. Carsten Eilers am : Flame und die Windows-Updates

Vorschau anzeigen
An Flame war ja anfangs eigentlich nichts besonderes, wenn man mal von der Größe und der Unfähigkeit der Antivirenhersteller, diesen Riesenschädling zeitnah zu entdecken, absieht. Einzig interessant schien die zumindest anf

Dipl.-Inform. Carsten Eilers am : SSL - Der nächste Nagel im Sarg?

Vorschau anzeigen
Es gibt mal wieder schlechte Nachrichten über SSL. Diesmal wurde mal keine Zertifizierungsstelle gehackt, stattdessen haben Forscher festgestellt, dass die Prüfung von Zertifikaten in anderer Software als Webbrowsern ziemlich mangelhaft

Dipl.-Inform. Carsten Eilers am : Code Signing - Auch Schadsoftware kann signiert sein

Vorschau anzeigen
Oracles Antwort auf Javas ständige Sicherheitsprobleme: Der Einsatz von Code Signing. Vorerst gibt es nur mehr oder weniger ausführliche Warnungen vor nicht oder falsch signierten Applets, irgendwann sollen dann nur noch signierte Apple

Dipl.-Inform. Carsten Eilers am : Einige Angriffe auf CAs im Überblick

Vorschau anzeigen
Das größte Problem bei der Sicherheit von SSL/TLS allgemein und HTTPS im besonderen ist und bleibt das bestehende Zertifizierungssystem. Es gibt einfach zu viele CAs, denen die Browser und Betriebssysteme ab Werk vertrauen. Stellt eine di