Certificate Transparency: Webanwendungen hacken, bevor sie installiert sind

Mit Certificate Transparency werden HTTPS-Zertifikate in öffentlichen Logs gespeichert. Das bringt mehr Sicherheit im TLS-Ökosystem, es führt aber auch zu überraschenden Gefahren für Webanwendungen wie Wordpress.

Artikel von Hanno Böck veröffentlicht am 29. Juli 2017, 0:56 Uhr

Certificate Transparency ist ohne Zweifel ein sinnvolles Sicherheitsfeature für TLS - aber es hat unerwartete Konsequenzen für andere Bereiche. (Bild: Certificate Transparency / Google)

This text is also available in English.

Das von Google entwickelte System Certificate Transparency ist inzwischen zu einem wichtigen Teil des TLS-Ökosystems geworden. In öffentlichen und kryptographisch verifizierbaren Logs werden Webseitenzertifikate gespeichert und können von jedem dort eingesehen werden. Das hat viel zur Aufklärung von Vorfällen wie den falsch ausgestellten Zertifikaten von Symantec beigetragen.

Doch Certificate Transparency hat auch Auswirkungen, die bislang kaum bedacht wurden. Die Zertifikate enthalten Informationen, die aus vielerlei Hinsicht interessant sein können - auch für Angreifer.

Hostnamen lassen sich nicht mehr geheim halten

Ein Webseitenzertifikat enthält üblicherweise einen Hostnamen. Damit kann es Aufschluss über Subdomains geben. So kann man beispielsweise die Certificate-Transparency-Suchmaschine crt.sh nutzen, um nach Subdomains einer Domain zu suchen. Hilfreich, wenn man beispielsweise nach allen Subdomains einer Firma suchen möchte, um sie nach Sicherheitslücken abzuklappern.

Ganz praktisch heißt das, dass Subdomains in aller Regel nicht mehr geheim sind - mit der Ausnahme von Wildcard-Zertifikaten oder wenn man die umstrittene Möglichkeit von Redacted-Labels in Certificate Transparency nutzt.

Interne Services unter nicht zu erratenden, "geheimen" Subdomains zu betreiben, war zwar schon immer eine schlechte Idee, da Subdomains immer unverschlüsselt im Datenverkehr mitgelesen werden können, aber durch Certificate Transparency wird das noch mal verdeutlicht.

Manche Zertifizierungsstellen tragen schon heute alle Zertifikate automatisch in öffentliche Logs ein. Symantec wurde von Google nach den ersten größeren Sicherheitsvorfällen 2015 dazu gezwungen. Sogenannte Extended-Validation-Zertifikate müssen sowieso in Logs eingetragen werden. Let's Encrypt trägt ebenso wie Cloudflare freiwillig alle ausgestellten Zertifikate in Logs ein.

Doch auch, wer nicht selbst loggt, findet üblicherweise seine Zertifikate schnell in den Logs wieder, denn der Crawler der Google-Suchmaschine trägt Zertifikate automatisch dort ein.

Bald werden sowieso alle Zertifikate geloggt. Ursprünglich hatten die Chrome-Entwickler angekündigt, das ab September zu verlangen, inzwischen die Deadline aber auf April 2018 verschoben. In der Praxis landen aber schon heute sehr viele Zertifikate schnell in Logs.