Original-URL des Artikels: https://www.golem.de/news/certificate-transparency-betrug-mit-tsl-zertifikaten-wird-fast-unmoeglich-1610-124024.html    Veröffentlicht: 25.10.2016 15:30    Kurz-URL: https://glm.io/124024

Certificate Transparency

Betrug mit TLS-Zertifikaten wird fast unmöglich

Alle TLS-Zertifizierungsstellen müssen ab nächstem Herbst ihre Zertifikate vor der Ausstellung in ein öffentliches Log eintragen. Mittels Certificate Transparency kann Fehlverhalten bei der Zertifikatsausstellung leichter entdeckt werden - das TLS-Zertifikatssystem insgesamt wird vertrauenswürdiger.

Google treibt das Certificate-Transparency-System voran: Ab Oktober 2017 müssen alle neu ausgestellten TLS-Zertifikate vorab in ein öffentliches Log eingetragen werden. Anderenfalls werden sie vom Chrome-Browser nicht mehr akzeptiert. Damit wird ein Missbrauch des Zertifikatssystems deutlich schwieriger. Wer unberechtigt Zertifikate ausstellt, fliegt mit hoher Wahrscheinlichkeit auf.

Alle Zertifikate werden geloggt

Der Kern von Certificate Transparency sind öffentliche Log-Server. Schon bisher wurden die meisten Zertifikate in die Logs eingetragen. Googles Webcrawler schickte alle Zertifikate, die von einer im Browser vorhandenen Zertifizierungsstelle ausgestellt waren, an eines der von Google betriebenen Logs. Grundsätzlich kann jeder Zertifikate in die Logs eintragen, wenn diese von den im Browser akzeptierten Zertifizierungsstellen ausgestellt wurden.

Mittels kryptographischer Verfahren wird garantiert, dass Zertifikate in die Logserver nur eingetragen und nicht daraus entfernt werden können. Das dahinterstehende Verfahren ähnelt in gewisser Weise einer Blockchain, wie sie bei Bitcoin zum Einsatz kommt.

In Zukunft müssen Zertifizierungsstellen ihre Zertifikate bereits vor der Ausstellung in die Logs eintragen. Dafür erstellen diese ein Vorzertifikat. In diesem Vorzertifikat sind bereits alle wichtigen Daten eingetragen, es fehlen lediglich die sogenannten Signed Certificate Timestamps (SCTs). Diesen SCT erhält die Zertifizierungsstelle anschließend von den Logservern. Sie sind ein signierter Beleg dafür, dass ein Zertifikat in ein Log eingetragen wurde. Um vom Browser akzeptiert zu werden, müssen Zertifikate künftig zwei SCTs von voneinander unabhängigen Logs enthalten. Die teureren Extended-Validation-Zertifikate mussten schon bisher zwei SCTs enthalten. Künftig wird diese Anforderung dann auf alle neu ausgestellten Zertifikate ausgedehnt.

Google legt dabei Wert darauf, dass mindestens eines der beiden Logs nicht von Google selbst betrieben wird. Damit soll verhindert werden, dass die gesamte Verantwortung für das System an einer Stelle konzentriert ist.

Log-Daten öffentlich zugänglich

Die Daten der Logs kann jeder einsehen. Mittels einer relativ simplen HTTP-API, die im RFC 6962 dokumentiert ist, kann man die Daten auslesen. Wer es etwas einfacher haben möchte, kann auch das von Comodo betriebene Webinterface unter crt.sh nutzen, das eine Suche nach geloggten Zertifikaten erlaubt.

Ein Log betreiben kann theoretisch jeder. Der Code dafür ist öffentlich verfügbar und steht unter der Apache-2.0-Lizenz. Allerdings wird nicht jedes Log automatisch vom Browser anerkannt. Chrome hat relativ strenge Anforderungen für die akzeptierten Logs. So müssen diese üblicherweise erreichbar sein und dürfen nur eine sehr geringe Downtime haben. Immer wieder wurden Logs in der Vergangenheit entfernt, weil sie diese Anforderungen nicht erfüllt haben. Kürzlich musste Google gar vermelden, dass das von Google selbst betriebene Aviator-Log für kurze Zeit die Anforderungen nicht erfüllte.

Üblicherweise dauert es etwa eineinhalb Stunden, bis ein Zertifikat ins Log eingetragen wird. Der Hintergrund ist ein relativ komplexes kryptographisches Verfahren, das mittels eines Merkle-Trees garantiert, dass das Log konsistent ist. In diesem Fall dauerte es jedoch über 26 Stunden. Der Grund dafür war, dass jemand mehrere Millionen ältere Zertifikate gleichzeitig in das Log eingetragen hatte.



Nichts unter den Tisch kehren

Der Zweck des gesamten Systems ist es, mehr Transparenz in die Ausstellung von Zertifikaten zu bringen. Immer wieder sorgen Zertifizierungsstellen für Negativschlagzeilen, weil sie Regeln nicht beachten oder aufgrund von Fehlern oder Sicherheitslücken Zertifikate unberechtigterweise ausstellen. Zuletzt häuften sich die Vorfälle bei der chinesischen Zertifizierungsstelle Wosign, so dass Mozilla letztendlich entschied, Wosign aus dem Browser zu entfernen. Auch Comodo musste in letzter Zeit mehrfach über Sicherheitslücken bei der Zertifikatsausstellung berichten.

Der große Vorteil von Certificate Transparency: Was auch immer die Zertifizierungsstellen machen, es ist nahezu unmöglich, etwas zu vertuschen. Einen großen Erfolg konnte Certificate Transparency bereits verbuchen: Im September 2015 hatte Symantec unberechtigterweise mehrere EV-Zertifikate testweise ausgestellt, einige davon für Google-eigene Domains. Symantec versuchte zunächst, das gesamte Ausmaß des Fehlers zu vertuschen. Vergeblich, denn alle fehlerhaft ausgestellten Zertifikate waren bereits in Googles Logservern vermerkt.

Doch nicht nur Fehlverhalten von Zertifizierungsstellen kann mit Certificate Transparency aufgedeckt werden. Das Sicherheitsteam von Facebook hatte von einem solchen Vorfall berichtet. Bei einem Check der Logs fiel auf, dass ein Zertifikat für eine Subdomain von fb.com ausgestellt wurde, von dem das Sicherheitsteam nichts wusste. Die Zertifikate wurden von einer anderen Abteilung von Facebook beantragt, allerdings hatte diese das Sicherheitsteam nicht - wie eigentlich vorgesehen - darüber informiert. Certificate Transparency half also dabei, eine interne Verletzung der Sicherheitspolicy von Facebook aufzudecken.

Unberechtigte Zertifikate entdecken

Für Betreiber von Webseiten bedeutet Certificate Transparency, dass sie ein mächtiges Tool bekommen haben, um unberechtigte Zertifikate zu entdecken. Empfehlenswert ist es, dass Webseitenbetreiber selbst gelegentlich die Logs prüfen und nach Zertifikaten Ausschau halten, die sie selbst nicht beantragt haben. Am einfachsten geht das über das bereits erwähnte Webinterface. Allerdings gilt hierbei natürlich, dass der Betreiber des Webinterfaces theoretisch falsche Daten ausgeben könnte. Wer absolut auf Nummer sicher gehen will, sollte die Daten der Logs selber auslesen und kryptographisch prüfen.



Unentdeckter Angriff fast unmöglich

Sollte ein Angreifer versuchen, unberechtigterweise ein Zertifikat auszustellen und dabei unentdeckt bleiben, sind die Hürden mit Certificate Transparency deutlich größer als bisher. Der Angreifer müsste zunächst die volle Kontrolle über den Zertifikatsausstellung erlangen. Eine Sicherheitslücke, die ihm nur erlaubt, ein Zertifikat für eine fremde Domain auszustellen, würde möglicherweise weiterhin zu einem Logvorgang führen und das Zertifikat wäre öffentlich einsehbar. Weiterhin muss der Angreifer verhindern, dass der Browser des Opfers mit den Logs kommuniziert und die Gültigkeit der SCTs prüft.

Selbst für diesen Fall hat Certificate Transparency ein Konzept vorgesehen, das eine Aufdeckung des Angriffs ermöglichen soll: Das sogenannte Gossip-Protokoll. Ein Browser, der die Logs gerade nicht erreichen kann, soll diesen Vorfall über möglichst viele verschiedene Kanäle verbreiten. Das könnten etwa Verbindungen zu anderen Webseiten sein. Um das Gossip-Protokoll gab es bereits viele Diskussionen, die Details sind noch nicht ausgearbeitet. Bislang existiert es nur als Entwurf.

Domainnamen sind öffentlich

Ein wichtiger Aspekt von Certificate Transparency ist, dass künftig alle Zertifikate samt Inhalt öffentlich sind. Das dürfte überwiegend Vorteile haben, aber es kann auch zu unerwünschten Nebeneffekten führen. Ein Webseitenbetreiber könnte etwa auf die Idee kommen, Inhalte unter einer geheimen Subdomain abzulegen. Wird für diese Subdomain ein Zertifikat ausgestellt, dann ist die Subdomain automatisch nicht mehr geheim. Ein ähnliches Problem könnte auftreten, wenn jemand eine Domain neu registriert und davon ausgeht, dass diese bisher niemandem bekannt ist und dort eine vorläufige, nicht für die Öffentlichkeit gedachte Webseite liegt.

Bereits jetzt könnte es zu derartigen Missverständnissen kommen. So beantragen viele Provider inzwischen automatisch Zertifikate über Let's Encrypt - und Let's Encrypt hat von Anfang an alle Zertifikate in öffentliche Logs eingetragen.

Eine Möglichkeit, die bei Subdomains Abhilfe schafft, sind Wildcard-Zertifikate. So kann ein Domaininhaber ein Zertifikat für *.example.org ausstellen lassen. Wildcard-Zertifikate sind üblicherweise deutlich teurer. Es gibt bislang keinen Anbieter, der diese kostenlos ausstellt.

Certificate Transparency sieht auch vor, dass Zertifikate geloggt werden, bei denen ein Teil des Domainnamens nicht sichtbar ist, sogenannte Redacted Certificates. Das geloggte Zertifikat würde dann einen Eintrag der Form ?.example.org enthalten, während das echte Zertifikat die korrekte Subdomain enthält. Dieses Feature wurde auf Wunsch vieler Zertifizierungsstellen eingeführt. Allerdings konnte man sich bisher nicht über eine genaue Vorgehensweise einigen, so dass Chrome diese Redacted Certificates bislang nicht akzeptiert. Trotzdem hatte Symantec bereits entsprechende Zertifikate an Kunden verkauft, was zu unerwarteten Fehlermeldungen führte.



Fazit: ein großer Schritt für mehr Sicherheit bei TLS

In der Vergangenheit stand das System der Zertifizierungsstellen oft in der Kritik. Hinter den Hunderten Zertifizierungsstellen stehen oft wenig vertrauenswürdige Organisationen, und sie sind theoretisch in der Lage, für beliebige Webseiten Zertifikate auszustellen.

Die Kritik daran ist einerseits berechtigt. Wie die erwähnten Vorfälle um Comodo, Symantec oder Wosign zeigen, läuft bei der Zertifikatsausstellung viel schief. Manche Kritiker allerdings gehen so weit, dass sie die Sicherheit von TLS und HTTPS wegen dieser Probleme generell infrage stellen. Das ist absurd.

Echte Angriffe sind selten

Echte Angriffe mittels kompromittierter Zertifizierungsstellen sind selten. Bei den allermeisten Vorfällen handelt es sich um Fehler, Sicherheitslücken, die vor einen Missbrauch entdeckt werden, oder Verletzungen von Policies. Die letzten bekannten Vorfälle, bei dem kompromittierte Zertifizierungsstellen tatsächlich für Angriffe missbraucht wurden, ereigneten sich 2011 bei Comodo und Diginotar. Bei einem weiteren Vorfall bei der Zertifizierungsstelle India CCA im Jahr 2014 ist nicht ganz klar, ob dieser Teil eines Angriffs war.

Technisch hat sich in den letzten Jahren einiges verbessert. Neben Certificate Transparency ist hier HTTP Public Key Pinning (HPKP) erwähnenswert - auch wenn es daran einige Kritik gibt, weil man dabei viel falsch machen kann.

Der Schritt von Google, das Certificate-Transparency-System voranzutreiben, wird dafür sorgen, dass Angriffe mittels fälschlicherweise ausgestellten Zertifikaten noch unwahrscheinlicher werden. Paradoxerweise könnte Certificate Transparency jedoch auch dazu führen, dass das System der Zertifizierungsstellen noch unsicherer erscheint - weil mehr Fehler aufgedeckt werden.  (hab)


Verwandte Artikel:
HTTPS: Fritzbox bekommt Let's Encrypt-Support und verrät Hostnamen   
(15.12.2017, https://glm.io/131705 )
HTTPS: Chrome will HTTP Public Key Pinning wieder aufgeben   
(29.10.2017, https://glm.io/130871 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
LLVM 6.0: Clang bekommt Maßnahme gegen Spectre-Angriff   
(09.03.2018, https://glm.io/133241 )
IT-Sicherheit: Nur acht Prozent der Chrome-Nutzer aktivieren noch Flash   
(07.03.2018, https://glm.io/133193 )

© 1997–2019 Golem.de, https://www.golem.de/