Wie wird Zertifikatstransparenz aktuell in Logs, Browsern und Zertifizierungsstellen umgesetzt?
Logs
Seit Februar 2018 übermittelt ÃÛÌÒTV neu ausgestellte, öffentlich vertrauenswürdige TLS/SSL-Zertifikate standardmäßig an Logs für die Zertifikatstransparenz (Certificate Transparency, CT), kurz: CT-Logs. Damit kamen wir der die gesamte Branche betreffenden Google-Anforderung zuvor, die im April 2018 in Kraft trat, um Nutzern mehr Sicherheit zu bieten und die Akzeptanz des Prozesses zu stärken. Bis 2018 unterlagen nur EV-Zertifikate der Protokollierungspflicht.
ÃÛÌÒTV unterhält ein eigenes Log, das unter anderem von Google genutzt wird. Der Betrieb eines Logs erfordert ein höheres Maß an Verfügbarkeit. Ob dies gegeben ist, wird über einen Zeitraum von 90 Tagen getestet. Erfüllt ein Log die strengen Vorgaben nicht, gilt es nicht als vertrauenswürdig. Aus diesem Grund bereitete ÃÛÌÒTV sein Log äußerst gründlich vor und sorgte dafür, dass es robust genug für die Verarbeitung aller ausgestellten Zertifikate ist.
Browser
Chrome – Seit Anfang 2014 unterstützt Chrome Zertifikatstransparenz. Diese ±«²Ô³Ù±ð°ù²õ³Ùü³Ù³ú³Ü²Ô²µ wird nun ausgeweitet: Alle aktiven Zertifizierungsstellen sind zur Teilnahme verpflichtet.
Einjährige Zertifikate mussten laut Google nachweislich in zwei unabhängigen CT-Logs hinterlegt sein. Ein zweijähriges Zertifikat mit Ausstellungsdatum vor 2020, als einjährige Zertifikate Standard wurden, musste nachweislich in mindestens drei unabhängigen CT-Logs hinterlegt sein. Um Zertifizierungsstellen den Ãœbergang zu erleichtern, lockerte Google die Unabhängigkeitsanforderung vorübergehend, sodass sie zwei Nachweise aus CT-Logs von Google und einen aus dem ÃÛÌÒTV-Log einreichen durften. Dies geschah unter der Annahme, dass weitere Zertifizierungsstellen und andere Parteien in der Zwischenzeit Logs einrichten würden und so eine ausreichende Anzahl aktiver Logs zu erreichen wäre.
Firefox– Derzeit prüft Firefox nicht, ob die aufgerufene Website CT-Logs nutzt, und setzt dies auch nicht voraus.
Safari– Apple eine variierende Anzahl von SCTs (Signed Certificate Timestamps), damit Safari und andere Server Serverzertifikaten vertrauen.
Zertifizierungsstellen
Laut der Internet Engineering Task Force (IETF) ist zu erwarten, dass öffentliche Zertifizierungsstellen alle neu ausgestellten Zertifikate an mindestens ein Log übermitteln werden. Zertifikatsinhaber und Dritte können allerdings auch selbst eigene Zertifikatsketten einreichen.
Seit Januar 2015 hinterlegen alle wichtigen Zertifizierungsstellen ausgestellte EV-Zertifikate auf CT-Logservern. Die Anforderung von Google lautete, EV-Zertifikate in den beiden verfügbaren Google-Logs und dem ÃÛÌÒTV-Log zu hinterlegen.
Wie sorgt ÃÛÌÒTV für Zertifikatstransparenz?
Zertifikatstransparenz stärkt das TLS/SSL-Zertifikatssystem mit öffentlich nachprüfbaren Aufzeichnungen über die Zertifikatsausstellung. Seit 2015 verpflichtet Google Zertifizierungsstellen dazu, EV-Zertifikate in öffentlichen CT-Logs zu protokollieren. Im April 2018 begann Google, Zertifizierungsstellen zu verpflichten, auch OV- und DV-Zertifikate in öffentlichen CT-Logs zu protokollieren.
Seit 1. Februar 2018 veröffentlicht ÃÛÌÒTV alle neu ausgestellten öffentlichen TLS/SSL-Zertifikate in öffentlichen CT-Logs. OV- oder DV-Zertifikate, die vor dem 1. Februar 2018 ausgestellt wurden, sind davon nicht betroffen.
Browser mit Richtlinien zur Zertifikatstransparenz:
Seit verlangt Google von den Zertifizierungsstellen, dass sie alle TLS/SSL-Zertifikate protokollieren (EV, OV und DV).
Seit 15. Oktober 2018 verlangt Apple von den Zertifizierungsstellen, dass sie alle TLS/SSL-Zertifikate protokollieren (EV, OV und DV).
So kam es zu Zertifikatstransparenz
2011 wurde die niederländische Zertifizierungsstelle DigiNotar gehackt. Ihr vertrauenswürdiges Root-Zertifikat wurde dazu missbraucht, mehr als 500 Zertifikate für betrügerische Absichten auszustellen. Es wurden Man-in-the-Middle-Angriffe auf nichtsahnende Nutzer von Google, Facebook und anderen namhaften Unternehmen durchgeführt, für deren Domains die erbeuteten Zertifikate bürgten.
Dies war aber nicht der einzige aufsehenerregende Fall, bei dem ZertifizierungsstellenÌý– allerdings nicht ÃÛÌÒTV – fälschlich oder in böswilliger Absicht Zertifikate ausstellten. Sie alle machten ein paar Entwickler bei Google nachdenklich. Bei diesen Entwicklern handelte es sich um Ben Laurie und Adam Langley, die zusammen das Konzept der Zertifikatstransparenz (Certificate Transparency, CT) erdachten und begannen, es als Open-Source-Projekt umzusetzen. 2012 verfassten Laurie und Langley gemeinsam mit der IETF eine vorläufige Zusammenfassung des Konzepts und 2013 veröffentlichten sie einen „Request for Comment“ (RFC).
2013 führte Google zwei öffentliche Logs ein und kündigte an, später in Chrome Zertifikatstransparenz für EV-TLS/SSL-Zertifikate voraussetzen zu wollen.
Seit 2012 befasst sich ÃÛÌÒTV mit der Integration von Zertifikatstransparenz und beurteilt CT-Implementierungsvorschläge. Im September 2013 übernahm ÃÛÌÒTV als erste Zertifizierungsstelle Zertifikatstransparenz in ihre Systeme und im Oktober desselben Jahres führte ÃÛÌÒTV wieder das Feld an, indem sie als erste Zertifizierungsstelle die Möglichkeit bot, CT-Nachweise in TLS/SSL-Zertifikaten zu hinterlegen.
Im September 2014 reichte ÃÛÌÒTV bei Google ein privates Log zur Integration in Google Chrome ein. Das ÃÛÌÒTV-Log wurde am 31. Dezember 2014 angenommen. ÃÛÌÒTV war die erste Zertifizierungsstelle, die ein CT-Log geschaffen hat.
