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.

Artikel veröffentlicht am 25. Oktober 2016, 15:30 Uhr, Hanno Böck

Mit Certificate Transparency versucht Google, das System der Zertifizierungsstellen vertrauenswürdiger zu machen. (Bild: Certificate Transparency / Google)

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.