Certificate Transparency (CT): wichtige Änderungen bei Ihren SSL/TLS-Zertifikaten (Update)

Googles Initiative „Certificate Transparency“ (CT) soll Zertifikate, die von Certificate Authorities (CAs) ausgestellt wurden, protokollieren, kontrollieren und überwachen. Die Idee dahinter ist, dass CAs keine Public Key-Zertifikate ausstellen sollen, ohne den Eigentümer der Domain darüber zu informieren. Chrome verlangt von allen CAs, dass diese über ihre gesamten EV-SSL-Zertifikate öffentliche Protokolle führen. So bleibt die grüne Adresszeile auch weiterhin aktiv. Welche genauen Änderungen geplant sind, verraten wir Ihnen gerne:

Hintergründe: Deshalb kam es zu CT

SSL/TLS-Zertifikate sind ein essenzieller Sicherheitsfaktor bei eCommerce-Transaktionen, E-Mail-Verkehr und beim Online-Banking. Die beiden Hauptaufgaben von SSL/TLS-Zertifikaten sind: Auf der einen Seite wird über Zertifikate die Verschlüsselung von Informationen zwischen dem Webbrowser und dem besuchten Webserver ermöglicht. Somit schützen Sie beispielsweise Kreditkartendaten vor dem Zugriff durch unbefugte Dritte. Auf der anderen Seite, und dies ist nicht weniger wichtig, wird dem Besucher einer Webseite ermöglicht, die Vertrauenswürdigkeit des Webseiten-Betreibers zu überprüfen.

CAs, die SSL-Zertifikate ausstellen, wie Symantec, Comodo oder SwissSign, können sich bei der Validierung der Angaben nicht den geringsten Fehler erlauben. Daher investieren vertrauenswürdige Zertifizierungsstellen viel Geld in die Qualifizierung ihres Personals und die zur Anwendung kommenden Sicherheitsstandards. Damit soll sichergestellt werden, dass die Standards zur Unternehmens-/Identitätsprüfung unter allen Umständen greifen, bevor organisationsvalidierte oder Extended Validation-(EV)-Zertifikate ausgestellt werden.

Leider arbeiten nicht alle augenscheinlich vertrauenswürdigen CAs nach denselben Standards, sodass in der Vergangenheit durchaus Zertifikate für bekannte Webseiten auch an nicht autorisierte Antragsteller ausgestellt wurden. Nun gilt es, diese falsch ausgestellten Zertifikate zeitnah ausfindig zu machen und den Schaden, der durch die nicht erlaubte Verwendung dieser Zertifikate entstanden sein kann, auf ein Minimum zu beschränken. Certificate Transparency (CT) möchte praktikable Werkzeuge bieten, um diesen Missstand zu korrigieren.

Die Praxis: So soll CT funktionieren

Vier elementare Teilnehmer sind bei der Certificate Transparency beteiligt: Certification Authorities (CAs), Log-Server (dienen als öffentliche Datenbanken für SSL/TLS-Zertifikate), Auditoren (Gegenstellen oder Webbrowser, die mit SSL-Zertifikaten arbeiten) und Monitoring-Dienste. Vor dem Ausstellen eines Zertifikats ist es notwendig, dass alle relevanten Informationen des Zertifikats durch die CA an mindestens einen Log-Server, dem die CA und die Auditoren gemeinsam vertrauen, geschickt werden. Der Log-Server empfängt nun das SSL-Zertifikat und antwortet der CA mit einer unveränderbaren und einzigartigen Bestätigung. Diese Signed Certificate Timestamp (SCT) genannte Bestätigung wird bei Ausstellung eines Zertifikats hinzugefügt. Es existieren auch andere Möglichkeiten der Nachweiserbringung, die wir Ihnen an anderer Stelle vorstellen werden.

Was ändert sich durch CT?

Wird durch den Browser eine SSL-geschützte Webseite aufgerufen, prüft der Browser das Zertifikat anhand einer offiziell vorbestimmten Checkliste. Certificate Transparency ergänzt das Prozedere durch eine zusätzliche Überprüfung, bei der Browser, die eine Auditorenrolle übernehmen, auch den SCT-Nachweis, welcher im Zertifikat inkludiert ist, überprüfen.

Die Überprüfung der SCT-Nachweise erfolgt unter Zuhilfenahme vertrauenswürdiger Log-Server. Für die Gültigkeit eines SCT-Nachweises gilt, dass der Webbrowser den Public-Key des ausstellenden Log-Servers in seiner lokalen Datenbank wiederfindet. Die angeforderte Überprüfung findet nicht in Echtzeit statt. Googles Browser Chrome ist im Augenblick der einzige Browser, der CT unterstützt. Im Rahmen von Certificate Transparency ist die Hauptaufgabe des Webbrowsers, bei den CAs durchzusetzen, dass die Zertifikatsausstellung öffentlich publiziert wird und der Nachweis direkt enthalten ist.

Jeder, der neu in den Log-Server aufgenommenen Zertifikate einsehen möchte, kann die CT-Monitoring-Dienste nutzen. Die Idee dahinter ist, dass man durch das Monitoren der Log-Server falsch ausgestellte SSL/TLS-Zertifikate für Webseiten ausfindig machen kann. Es ist nicht notwendig, dass SCT-Nachweise direkt in das Zertifikat implementiert werden. Denn auch TLS-Erweiterungen oder OCSP-Stapelung können dies übermitteln. Jedoch sind hierfür spezielle Konfigurationen auf Seiten des Webservers notwendig. CT eignet sich also, um alle ausgestellten Zertifikate in einer oder mehreren Datenbanken zugänglich zu machen. Dabei bleibt es dem Browser überlassen, wie er sich verhält, sollte sich eine CA dazu entschieden haben, die ausgestellten Zertifikate nicht auf Log-Servern zu veröffentlichen.

Es ist sehr wahrscheinlich, dass Googles Browser Chrome keine grüne Omnibox darstellt, wenn die EV-Zertifikate keine Nachweise zur CT enthalten. Möglich wäre auch, dass man statt der Überprüfung von öffentlichen Archiven die Zertifikate überprüft, die öffentlich zugänglich sind. Jedoch würde dies ungleich mehr Zeit beanspruchen. Dieser Zeitvorteil ist der eigentliche Ansatz in Sachen Certificate Transparency. Momentan kann, aufgrund fehlender CT-Auditoren, das volle Potenzial von CT nicht genutzt werden. Neben Google hat kein anderer Browser-Anbieter angekündigt, CT zu unterstützen. Klar ist, dass neben den Browsern auch die Desktop-Anwendungen, Applikationen auf Mobilgeräten und webbasierte Dienste nachziehen müssen, wenn diese Teil der SSL-Welt sind.

CT-Monitoring stellt also soweit die bessere und zügigere Methode bei der Entdeckung falscher SSL-Zertifikate dar – verglichen mit dem umständlichen Scannen des Internets. Zugleich wird nicht jeder Inhaber eines SSL-Zertifikats die Mittel zur Verfügung haben, um sich Certificate Transparency-Monitore anschaffen zu können. Dies wird sich auf die größeren Unternehmen beschränken.

Existieren Alternativen zu CT?

Festzuhalten gilt, dass CT nicht die Problematik der falsch ausgestellten Zertifikate löst. Vielmehr ist es wesentlich einfacher, die falsch ausgestellten zu ermitteln. Alternativ lassen sich andere Wege beschreiten. CCA, zum Beispiel. Dabei werden die unautorisiert ausgestellten Zertifikate anders ermittelt. Mit CCA werden in den DNS-Einstellungen die CAs benannt, die Zertifikate für die eigene Domain ausstellen dürfen. CAs, die CAA unterstützen, sollten zunächst den erforderlichen CAA-Eintrag in den DNS-Einstellungen prüfen, bevor Zertifikate ausgegeben werden. Dies ist jedoch momentan noch nicht verbindlich geregelt. Würden Auditoren und Browser dies durchsetzen, gäbe es eine zusätzliche effektive Methode zur Vermeidung von unautorisiert ausgestellten Zertifikaten.

Und wie steht es um den Datenschutz?

Aus Sicht des Datenschutzes ist CT eine echte Herausforderung. Denn jeder legitimer Webseitenbetreiber hat mit CT-fähigen Browsern Schwierigkeiten bei der Darstellung der grünen Adressleiste, insofern er nicht bereit ist, seine Zertifikatsinformationen in der Datenbank der Log-Server anzuzeigen. Ein möglicher Grund dafür wäre beispielsweise ein SSL-Zertifikat für ein noch in der Entwicklung befindliches Produkt oder ein Regierungsprojekt, welches der Geheimhaltung unterliegt. Es müssen also Möglichkeiten geschaffen werden, den Datenschutz auch bei umfassender CT-Unterstützung zu gewährleisten.

Die PSW GROUP unterstützt Sie!

Sie sehen: CT steckt noch in den Kinderschuhen, Cyberkriminalität durch falsche SSL-Zertifikate kann hingegen schon laufen. Haben sich für Sie Fragen ergeben, nutzen Sie gern unseren Support, der Sie auch zurückruft. Allgemeine Fragen zum Thema können Sie auch in den Kommentaren stellen, sodass andere Fragesteller ebenfalls direkt Antworten erhalten.

27.10.16 – Update: Google treibt Certificate Transparency voran

Google treibt seine Initiative „Certificate Transparency“ voran: Der Suchmaschinenriese erklärt, dass voraussichtlich ab Oktober 2017 alle neu ausgestellten SSL/TLS-Zertifikate vor Ausstellung in das öffentliche Log eingetragen werden müssen. Geschieht das nicht, akzeptiert Googles Browser Chrome die Zertifikate nicht mehr.

Das erschwert das Missbrauchen des Zertifikate-Systems ungemein: unberechtigt ausgestellte Zertifikate fliegen höchstwahrscheinlich auf.

Transparenz: Log-Daten kann jeder einsehen

Jeder kann die Daten der Logs einsehen. Das Auslesen der Daten geschieht mittels HTTP-API gemäß der Dokumentation im RFC 6962. Alternativ kann das Webinterface unter crt.sh, welches Comodo betreibt, genutzt werden.

Im Schnitt dauert es rund 1,5 Stunden, bis ein SSL/TLS-Zertifikat im Log erfasst ist. Im Hintergrund werkelt ein recht komplexes Kryptografie-Verfahren, das mittels Merkle-Trees für konsistente Logs sorgt.

CT: was soll das Ganze noch mal?

Pannen von Zertifizierungsstellen, jüngst machten etwa WoSign und StartCom von sich Reden, werden mit Certificate Transparency womöglich bald komplett der Vergangenheit angehören. Denn das Vertuschen etwaiger Fehler durch Zertifizierungsstellen wird nahezu unmöglich! Googles Logserver vermerken mit CT jedes falsch ausgestellte Zertifikat.

Auch andere Pannen kann CT aufdecken. So berichtete etwa Facebooks Sicherheitsteam von einem Vorfall: Für eine Subdomain von fb.com wurde ein Zertifikat ausgestellt, über das das Sicherheitsteam nichts wusste. Fälschlicherweise hatte eine andere Abteilung dieses Zertifikat beantragt, ohne das Sicherheitsteam darüber zu informieren. Beim Checken der Logs fiel die interne Verletzung der Facebook-Sicherheitsrichtlinie auf.