Die Sichtbarkeitslücke bei Certificate Transparency

Certificate Transparency (CT) war so erfolgreich, dass die meisten Menschen es für einen verpflichtenden Bestandteil des öffentlichen PKI-Ökosystems halten. Das liegt vermutlich daran, dass die meisten von uns typischerweise nur mit Zertifikaten für Websites zu tun haben, und für diese ist CT verpflichtend… sozusagen, aber eigentlich nicht zwangsläufig.

Die eigentliche Wahrheit ist, dass CT es nie auf die Agenda des CA/Browser Forums geschafft hat und nicht in den Baseline Requirements enthalten ist, dem Hauptdokument zur Regelung der Zertifikatsausstellung. Es gibt mehrere Erwähnungen von Precertificates (ein Artefakt der CT-Implementierung), aber kein Wort darüber, ob CAs CT nutzen sollten. In der Theorie und oft auch in der Praxis bleibt CT optional.

Certificate Transparency ist ein Mechanismus, der darauf ausgelegt ist, ein gewisses Maß an Kontrolle über das Handeln der vertrauenswürdigen Zertifizierungsstellen (CAs) auszuüben. Diese CAs bilden das Herzstück der Web-PKI und haben die Macht, Zertifikate für jede Domain weltweit auszustellen – ohne dass technische Kontrollen dies überprüfen. Historisch gesehen hat das zu vielen Problemen geführt.

CT verschiebt dieses Gleichgewicht, indem verlangt wird, dass alle ausgestellten Zertifikate protokolliert werden, das heißt öffentlich veröffentlicht werden. Im Rahmen der Zertifikatsausstellung reichen CAs ihre Zertifikate bei CT-Logs ein und betten Signaturen dieser Einreichungen in die Zertifikate ein. Entscheidend ist, dass CT von User-Agents durchgesetzt wird, die die Möglichkeit haben, jedes Zertifikat abzulehnen, für das kein ausreichender Protokollierungsnachweis vorliegt.

Wie hilft uns das? Nun, es zwingt böswillige Akteure ins Licht der Öffentlichkeit. Wenn jemand anderes als Sie ein Zertifikat für eine Ihrer Domains erhält, können Sie dies nun im globalen Strom öffentlicher Zertifikate beobachten und reagieren. Niemand wacht einfach eines Tages auf und beschließt, den CT-Firehose zu überwachen, aber es gibt Unternehmen, die Monitoring als Dienstleistung anbieten. (Red Sift ist eines davon.)

Es ist entscheidend, dass Sie ein Monitoring eingerichtet haben – ohne dieses passiert nichts. Vor ein paar Jahren erhielten beispielsweise Strafverfolgungsbehörden [angeblich] in Deutschland ein Zertifikat für jabber.ru und nutzten es zum Abfangen von XMPP-Verkehr. Es war in den CT-Logs vorhanden, aber niemand schaute hin, und das Abfangen blieb länger unentdeckt. In einem anderen Fall stellte FINA, eine kleine CA aus Kroatien, wiederholt fehlerhafte Zertifikate für die zu Cloudflare gehörende IP-Adresse 1.1.1.1 aus, die monatelang unentdeckt blieben.

Auf der positiven Seite profitieren Sie selbst dann von einer abschreckenden Wirkung, wenn Sie CT nicht überwachen, da fehlerhaft ausgestellte Zertifikate für immer als öffentlich einsehbarer Nachweis bestehen bleiben. Ihre Gegner wissen möglicherweise gar nicht, ob Sie überwachen oder nicht.

Wir haben bereits festgestellt, dass CT technisch gesehen nicht verpflichtend ist. Es kommt jedoch vor, dass einige der größten Zertifikatsnutzer es dennoch verlangen. Apple, Google, Microsoft und Mozilla verlangen CT alle an unterschiedlichen Stellen in ihren Produkten. In der Praxis müssen Sie, wenn Sie eine Website veröffentlichen, die von einem Browser genutzt werden soll, ein Zertifikat verwenden, das bei CT veröffentlicht wurde.

Aber nicht alle User-Agents sind Browser, und das Internet besteht aus mehr als nur Websites.

Ein CT innewohnendes Problem ist, dass es auf Client-Ebene durchgesetzt wird. Viele Clients, die CT nicht kennen, bieten überhaupt keinen Schutz. Deshalb können Ihre Gegner CT vollständig umgehen, und Sie profitieren nicht von seinem Schutz.

Moderne Browser verlangen CT, ebenso wie die offiziellen Netzwerkbibliotheken auf Apples Plattformen und seit Kurzem auch Android. Es gibt jedoch eine ganze Reihe von Programmiersprachen und TLS-Bibliotheken, die sich nicht darum kümmern. So gut wie alles, was kein Browser ist, ignoriert CT. Ihre API-Server werden, selbst wenn Sie heute CT-Zertifikate verwenden, tatsächlich nicht durch CT geschützt. Server-zu-Server-Kommunikation (z. B. SMTP) ist ebenso gefährdet. Für bestimmte Anwendungsfälle bietet CT überhaupt keinen Nutzen.

Langfristig ist die einzige Lösung, dass CT in die Baseline Requirements aufgenommen wird, was vermutlich nur geschehen wird, wenn eines der Root-Stores dies verlangt.

Die Situation wird durch die Post-Quanten-Migration verkompliziert. Um der drohenden Gefahr eines kryptografisch relevanten Quantencomputers zu begegnen, arbeitet Google an einem neuen Zertifikatstyp, der called Merkle Tree Certificates (MTC) genannt wird. Im Rahmen dieser Bemühungen wird Certificate Transparency neu aufgebaut und mit der Zertifikatsausstellung kombiniert. Es ist möglich, dass wir in Zukunft zwei Zertifikatstypen haben werden: MTC und X.509 mit Post-Quanten-Kryptografie. Ersteres wird den Vorteil der Transparenz bieten, aber es ist unklar, was im letzteren Fall geschehen wird.

Es gibt jedoch einen Weg.

Ohne Ihr Zutun kann jede CA ein Zertifikat für jeden Ihrer Domainnamen ausstellen. Es existiert jedoch ein Mechanismus, mit dem Sie die Ausstellung pro CA einschränken können, sogar pro CA-Konto. Er wird Certification Authority Authorization (CAA) genannt. CAA kann verwendet werden, um Ausstellungsrichtlinien zu erstellen und zu verteilen, die alle CAs beachten müssen. Dieser Mechanismus ist nicht narrensicher, aber alle CAs müssen ihn verpflichtend unterstützen.

Um die CT-Sichtbarkeitslücke zu schließen, müssen Sie nur mit CAs zusammenarbeiten, die sich verpflichtet haben, alle ihre Zertifikate bei CT zu protokollieren. Let's Encrypt, die nach Ausstellungszahlen größte und kostenlose CA, hat schon immer alles protokolliert. Es gibt vermutlich auch andere CAs, die dasselbe tun; wenn Sie sich nicht sicher sind, fragen Sie Ihre CA nach einer offiziellen Stellungnahme dazu.

Als Beispiel für eine positive Entwicklung haben sich kürzlich auch Amazon und DigiCert verpflichtet, alles zu protokollieren. Ihre Entscheidungen könnten mit den Änderungen zusammenhängen, die Chrome kürzlich in diesem Bereich vorgenommen hat. Laut der Formulierung in Version 1.8 ihrer Root-Richtlinie ist die Protokollierung von Precertificates verpflichtend, die Protokollierung von Zertifikaten bleibt jedoch eine SHOULD-Empfehlung.

Wenn Sie mehr erfahren möchten, haben wir ein Whitepaper, das genauer darauf eingeht, wie Sie die CT-Sichtbarkeitslücke schließen und CAA nutzen können, um Kontrolle über Ihre öffentlichen PKI-Bestände zu erlangen: High-Assurance Certificate Transparency Monitoring. Dieser Leitfaden kann Sie dabei unterstützen, die CT-Sichtbarkeitslücke zu schließen, aber auch bei anderen Aspekten der PKI-Sicherheit, einschließlich des Erreichens des heiligen Grals der PKI – der starken kryptografischen Validierung der Zertifikatsausstellung.