Dipl.-Inform. Carsten Eilers

Der Rückruf von Zertifikaten funktioniert generell nicht besonders zuverlässig. Für den Rückruf gibt es zwei Möglichkeiten: Eine Onlineprüfung über das Online Certificate Status Protocol (OCSP) oder ein Vergleich mit den von den Zertifizierungsstellen herausgegebenen Zertifikats-Rückruflisten (Certificate Revocation List, CRL). Ein Angreifer, der sich als ein bestimmter Server ausgeben kann, sitzt meist in der Internetverbindung des Opfers und kann dann auch die Prüfung der Zertifikate fälschen oder einfach unterbinden. Außerdem gibt es viele weitere Gründe, warum die Onlineprüfung fehl schlagen kann. Weshalb die Browser im Allgemeinen bei einem Fehlschlag der Prüfung auch einfach so tun, als wenn nichts passiert wäre, statt dem Zertifikat sicherheitshalber zu misstrauen. In Google Chrome ist die Onlineprüfung deshalb auch per Default ausgeschaltet.

Google Chrome prüft gar nicht online

Adam Langley hat die Hintergründe sehr gut zusammengefasst. Seinem Rat "No, don't enable revocation checking" möchte ich aber nicht unbedingt folgen. Auch wenn ein Angreifer die Zertifikatsprüfung unterlaufen kann bedeutet dass ja nicht automatisch, dass er es auch wirklich tut. Vielleicht verschläft er diesen Teil des Angriffs ja, auch wenn das unwahrscheinlich ist. Aber es erhöht den Aufwand für den Angriff, wenn auch nur minimal. Und man muss es den Angreifern ja nicht leichter machen als nötig, oder?

Google verwendet für Chrome eine eigene Lösung zur Prüfung von Zertifikaten: Die sogenannten CRLSets werden über Chromes Update-Funktion verteilt und enthalten die zurückgerufenen Zertifikate, die Google für wichtig hält. Wenn man von einem allmächtigen Angreifer ausgeht müsste man aber eigentlich auch davon ausgehen, dass er die Auslieferung der CRLSets verhindert oder manipuliert, oder?

"Mangelhafte" Zertifikate

Aber kommen wir zurück zu den Zertifikatsrückrufen allgemein. Ein weiteres Problem sind Zertifikate, für die mangels Angabe eines URL für das OCSP im Endeffekt in manchen Browsern kein Rückruf möglich ist. Denn dann kann der Status des Zertifikats nur über die Zertifikats-Rückruflisten geprüft werden, was zum Beispiel Firefox seit Firefox 28 gar nicht mehr macht (und davor auch nur für die erweiterten EV-Zertifikate als Fallback-Lösung verwendet hat, für normale Zertifikate wurde die CRL nie verwendet).

Falls ein Zertifikat weder einen URL für OCSP noch für die CRL enthält, kann es überhaupt nicht zurückgerufen werden, da niemand weiß, wo man nachfragen soll, ob das Zertifikat noch gültig ist oder nicht. Als Beispiel nennt Netcraft das Zertifikat für www.cloudpeople.it.

Die CRLs werden gross - SEHR gross

Ein weiteres Problem ist die durch den Heartbleed-Bug entstehende Masse an Rückrufen, die die CRLs gewaltig aufblähen. Zum Beispiel hat der Rückruf aller von CloudFlare genutzten Zertifikate die CRL von GlobalSign um rund 134.000 Einträge wachsen lassen. Wer möchte schon mehrmals täglich mehrere etliche MB (die CRL von GlobalSign umfasst jetzt 4,5MB) große Dateien herunter laden, nur um einzelne Domains zu prüfen? Zumal die Server, die die CRL bereit stellen, mitunter auch noch überlastet sind.

Vom ISC gibt es eine Grafik der Rückrufe pro Tag. Zum Glück sind bisher bei den OCSP-Servern keine Performanceprobleme aufgetreten, da hier ja nur einzelne Domains nachgefragt und nicht alle vorhandenen Daten heruntergeladen werden.

Mobile Browser sind unsicherer

Ein weiteres Problem sind die Mobile-Browser Die sind in Hinblick auf Sicherheitsfunktionen allgemein schon eingeschränkt, und die Zertifikatsprüfung macht da keine Ausnahme. Im Grunde ist nur eine Prüfung über OCSP möglich, die CRLs werden für einen mobilen Einsatz einfach zu groß. Und wenn die Browser oder Systeme dabei dann patzen, wird es unschön.

War da was?

Kommen wir zuletzt zu einem Problem auf der Benutzer-Seite: Woher weiß man denn, ob ein Server ein möglicherweise kompromittiertes Zertifikat verwendet? Potentiell gefährlich sind alle Zertifikate, die vor der Installation des am 7.4.2014 veröffentlichten (wann es installiert wurde ist eine andere Frage) Updates ausgegeben wurden. Das lässt aber etliche Kombinationen zu:

• Der Server verwendet OpenSSL gar nicht - es besteht generell keine Gefahr.
• Der Server verwendet OpenSSL, aber keine der betroffenen Versionen - es besteht generell keine Gefahr.
• Der Server verwendet immer noch OpenSSL in einer der betroffenen Versionen - Angriffe sind immer noch möglich, solche Server sollte man möglichst meiden.
• Der Server verwendete eine betroffene OpenSSL-Version, die inzwischen aber durch die aktuelle Version ersetzt wurde. Hier gibt es zwei Möglichkeiten:
  • Das Zertifikat wurde nach der Installation des Updates erneuert - es besteht keine Gefahr, aber dem alten Zertifikat darf nicht mehr vertraut werden.
  • Das Zertifikat wurde nach der Installation des Updates nicht erneuert - diesem Zertifikat sollte nicht vertraut werden, denn ein Angreifer könnten den privaten Schlüssel ausgespäht haben und sich nun als der betreffende Server ausgeben. Außerdem kann er die Kommunikation entschlüsseln.

Das Problem ist nur: Woher weiß man, ob ein Server betroffen war? Und ob er ein möglicherweise kompromittiertes Zertifikat weiter verwendet? Einige Test-Tools im Internet berücksichtigen auch die Entwicklung der Server, zum Beispiel die Tests von LastPass und den SSL-Tools.net. Netcraft hat einen "Heartbleed Indicator" als Erweiterung für Google Chrome, Opera und Firefox veröffentlicht. Der zeigt, ausgehend von Netcrafts SSL Survey Daten, an, ob ein Server von der Heartbleed-Schwachstelle betroffen war und ob er ein möglicherweise kompromittiertes Zertifikat verwendet.

Die Tests sind aber nur so zuverlässig wie die zugrunde liegenden Daten, da die reine Prüfung des Ausgabedatums des Zertifikats nicht ausreicht. Mitunter werden die Zertifikate erneuert und das Ausgabedatum beibehalten. Im Prinzip kann man also nur den Angaben der Server-Betreiber vertrauen. Mit der Einschränkung, dass denen bei einem kompromittierten Zertifikat ja nicht zu trauen ist - man könnte statt mit dem richtigen Server auch mit einem Angreifer verbunden sein, oder der Angreifer könnte sich als Man-in-the-Middle in die Verbindung zum Server eingeklinkt haben.

Eigentlich müsste man das ganze SSL/TLS auf dem Müllhaufen der Geschichte entsorgen und von Grund auf neu entwickeln. Aber das wird so schnell nicht passieren. Und die Weiterentwicklung von TLS läuft ja ziemlich schleppend. Um es mal höflich zu formulieren.

Carsten Eilers