CT – Certificate Transparency

Abkürzung: CT

Das zugrunde liegende Problem ist eine Lücke im Vertrauensmodell des Webs: Jede der weltweit anerkannten Zertifizierungsstellen kann ein Zertifikat für jeden Namen ausstellen. Ein Browser, dem ein Zertifikat vorgelegt wird, prüft die Kette und akzeptiert sie — er hat keine Möglichkeit festzustellen, ob der Betreiber des Namens von dieser Ausstellung überhaupt weiß.

Genau das ist mehrfach schiefgegangen, am sichtbarsten 2011 bei einer niederländischen Zertifizierungsstelle, deren Einbruch zu echten Zertifikaten für fremde Namen führte. Die Entdeckung dauerte Wochen.

Certificate Transparency dreht die Logik um: Nicht die Ausstellung wird verhindert, sondern ihre Verborgenheit. Siehe Zertifikatskette.

Der Log und sein Merkle-Baum

Ein CT-Log ist ein Verzeichnis, dem Einträge nur angehängt werden können. Löschen, Ändern und Umsortieren sind ausgeschlossen, und zwar nicht durch Zusage des Betreibers, sondern durch die Bauweise.

Dafür liegt über allen Einträgen ein Hashbaum: Je zwei Einträge werden gemeinsam gehasht, deren Ergebnisse wieder paarweise, bis an der Spitze ein einzelner Wert steht. Dieser Wurzelwert ändert sich bei jeder Veränderung irgendwo im Baum.

Daraus ergeben sich zwei Nachweise, die den Kern des Verfahrens bilden:

Zugehörigkeitsnachweis. Für einen einzelnen Eintrag genügt eine kurze Kette von Hashwerten, um zu belegen, dass er in einem Baum mit genau dieser Wurzel enthalten ist. Für Millionen Einträge sind das wenige Dutzend Werte.

Konsistenznachweis. Ein Log kann belegen, dass ein neuer Baum den alten vollständig enthält und nur ergänzt wurde. Damit lässt sich prüfen, dass das Log seine Geschichte nicht nachträglich umgeschrieben hat.

Der SCT

Reicht eine Zertifizierungsstelle ein Zertifikat beim Log ein, erhält sie eine signierte Bestätigung zurück: den Signed Certificate Timestamp. Er sagt zu, dass dieser Eintrag innerhalb einer festgelegten Frist im Log erscheint.

Dieser Nachweis muss den Browser erreichen, und dafür gibt es drei Wege:

Der erste Weg erklärt eine Eigentümlichkeit des Verfahrens: Das Zertifikat muss schon eingereicht werden, bevor es fertig ist. Dafür wird ein Vorzertifikat eingereicht, das denselben Inhalt trägt, aber als nicht verwendbar gekennzeichnet ist.

Was die Browser verlangen

Die Durchsetzung läuft nicht über die Norm, sondern über die Wurzelzertifikatsprogramme. Chrome verlangt seit 2018 für alle neu ausgestellten öffentlich vertrauenswürdigen Zertifikate einen CT-Nachweis, Apple ebenso. Gefordert sind Bestätigungen aus mehreren Logs verschiedener Betreiber, damit ein einzelnes Log die Prüfung nicht unterlaufen kann.

Praktisch heißt das: Ein Zertifikat ohne gültige SCTs wird abgewiesen, unabhängig davon, wie einwandfrei die Kette ist. Für Betreiber ist CT damit keine Option, sondern eine Voraussetzung — allerdings eine, die die Zertifizierungsstelle erfüllt und die man im Normalbetrieb nicht bemerkt.

Die drei Rollen

Logs nehmen Einträge an und liefern Nachweise. Betrieben werden sie von einigen großen Anbietern, darunter Zertifizierungsstellen und Betreiber von Infrastrukturdiensten.

Monitore lesen die Logs mit und melden, was sie finden. Das ist die Rolle, die für Betreiber praktisch zählt: Wer seine Domains überwachen lässt, erfährt von jedem Zertifikat, das irgendwo für seinen Namen ausgestellt wird — auch von dem, das er nicht beauftragt hat.

Auditoren prüfen, ob die Logs sich korrekt verhalten, insbesondere ob die Konsistenznachweise aufgehen.

Was CT leistet und was nicht

Es verhindert keine Fehlausstellung. Ein falsches Zertifikat entsteht trotzdem — es wird nur unweigerlich sichtbar. Der Schutz ist Entdeckung, nicht Verhinderung, und er wirkt vor allem abschreckend: Eine Zertifizierungsstelle, deren Fehlverhalten binnen Stunden öffentlich wird, verliert ihre Aufnahme in die Wurzelprogramme.

Es ersetzt kein CAA. Die beiden ergänzen sich sauber: CAA legt vorab fest, wer ausstellen darf; CT macht hinterher nachprüfbar, wer ausgestellt hat.

Es hilft nur bei öffentlich vertrauenswürdigen Zertifikaten. Eine firmeneigene Zertifizierungsstelle, deren Wurzelzertifikat auf den Geräten verteilt wurde, unterliegt der Anforderung nicht.

Die Nebenwirkung: Namen werden öffentlich

Das wird regelmäßig unterschätzt. Jeder Name, für den ein öffentliches Zertifikat ausgestellt wird, landet dauerhaft in einem durchsuchbaren Verzeichnis — auch vpn-test., jira-intern. oder kunde-xy.. Die Logs sind öffentlich zugänglich und werden von Suchdiensten erschlossen.

Für Angreifer ist das eine bequeme Quelle zur Erkundung einer Infrastruktur. Wer das vermeiden will, hat zwei Möglichkeiten: ein Platzhalterzertifikat verwenden, bei dem nur die Domain selbst im Log steht, oder interne Namen nicht über eine öffentliche Zertifizierungsstelle beziehen.

Umgekehrt ist dieselbe Offenheit ein nützliches Werkzeug — die Suche in den Logs findet vergessene Zertifikate, abgelaufene Testsysteme und Namen, von denen die eigene Dokumentation nichts weiß.

Wirkung

Der deutlichste Fall war 2015, als über die Logs auffiel, dass eine große Zertifizierungsstelle Zertifikate für Namen ausgestellt hatte, die ihr nicht gehörten — darunter solche für eine fremde, prominente Domain. Was als Testvorgang bezeichnet wurde, zog eine Untersuchung nach sich, in deren Verlauf diese Zertifizierungsstelle ihre Anerkennung in den Browsern verlor und ihr Geschäft abgab.

Dass ein solcher Vorgang nicht mehr unentdeckt bleibt, ist der eigentliche Ertrag des Verfahrens.

Reifegrad

Bemerkenswert für etwas so breit Durchgesetztes: Beide Fassungen sind als Experimental veröffentlicht — RFC 6962 von 2013 und die überarbeitete Fassung RFC 9162 von 2021. Die Verbindlichkeit kommt vollständig aus den Wurzelprogrammen der Browserhersteller, nicht aus dem Standardisierungsweg.