- Anzeigen -


Sie sind hier: Home » Fachbeiträge » Grundlagen

Was ist Certificate Transparency?


Was versteht man unter Certificate Transparency oder der CT-Richtlinie?
Hier finden Sie alles Wissenswerte zu Certificate Transparency (CT), z. B. wie sie funktioniert und wie Sie Googles Konformitätsanforderungen erfüllen



Autor: GlobalSign

Möglicherweise haben Sie schon vor einigen Jahren von Certificate Transparency (CT) gehört, als Google die Anforderung für alle Extended Validation (EV) SSL/TLS-Zertifikate ankündigte, die nach dem 1. Januar 2015 ausgestellt worden sind. Seitdem hat Google die Anforderung auf alle Arten von SSL-Zertifikaten ausgedehnt und zuletzt eine Frist bis zum April 2018 gesetzt. Zertifikaten, die nicht CT-qualifiziert sind und die nach diesem Datum ausgestellt werden, wird in Chrome nicht vertraut.

GlobalSign hat im Hintergrund bereits daran gearbeitet, dass alle Zertifikate mit CT ausgestattet werden - Extended Validation (EV) seit 2015, Domain Validated (DV) seit August 2016 und Organisation Validated (OV) ab Oktober 2017 – GlobalSign-Kunden sind damit für den Fristablauf seitens Google gerüstet.

Für alle, die sich immer noch fragen, worum es bei CT geht, hat GlobalSign die wichtigsten Informationen zusammengestellt.
Hinweis: Aus Gründen der Einfachheit verwenden wir in diesem Beitrag den Begriff SSL anstelle von TLS (mit einer Ausnahme), da er häufiger benutzt wird.

Certificate Transparency ist eine offene Rahmenstruktur für die Überwachung von SSL-Zertifikaten. Domaininhaber halten es vielleicht für sinnvoll, die Zertifikatausstellung für ihre Domain zu überwachen und darüber auch falsch ausgestellte Zertifikate zu erkennen. Vor CT gab es keine effiziente Möglichkeit, eine umfassende Liste der für Ihre Domain ausgestellten Zertifikate zu bekommen.

Mit CT werden alle Zertifikate öffentlich bekannt gegeben, was einen tieferen Einblick und mehr Transparenz innerhalb des Web-PKI-Ökosystems gestattet. Das Projekt zur Certificate Transparencywill drei Ziele erreichen:

1. Es für eine CA unmöglich (oder zumindest sehr schwer) zu machen, ein SSL-Zertifikat für eine Domain auszustellen, ohne dass das Zertifikat für den Eigentümer dieser Domain sichtbar ist.

2. Ein offenes Überprüfungs- und Überwachungssystem bereitzustellen, mit dem alle Domaininhaber oder CAs feststellen können, ob Zertifikate irrtümlich oder mit einer böswilligen Absicht ausgestellt wurden.

3. Benutzer vor irrtümlich oder mit einer böswilligen Absicht ausgestellten Zertifikaten zu schützen.

Über das Certificate Transparency Framework kann man falsch ausgestellte Zertifikate schnell und effizient erkennen.
Anders als im alten System, bei dem unberechtigte Zertifikate Wochen oder Monate im Umlauf bleiben und potenziell verheerende Schäden anrichten, bevor sie entdeckt werden. Die frühzeitige Erkennung von verdächtigen Zertifikaten ermöglicht es CAs und Domaininhabern, schnell zu handeln und die Zertifikate zu widerrufen.

So funktioniert Certificate Transparency

Die beiden wichtigsten CT-Komponenten sind die CT-Logs und Monitore.
CT-Logs führen Aufzeichnungen von ausgestellten SSL-Zertifikaten. Diese Logs sind 'append-only', d. h. sobald ein Zertifikat in einem Log eingetragen wurde, können die Einträge weder gelöscht noch geändert werden. SSL-Zertifikate und Vorzertifikate (mehr dazu weiter unten) können in CT-Logs eingetragen werden. Beim Erhalt eines gültigen SSL-Zertifikats oder Vorzertifikats gibt das Log einen Signed Certificate Timestamp (SCT) zurück.Dieser weist nach, dass das Log die Anfrage erhalten hat. CT-Logs verwenden einen kryptografischen Mechanismus namens "Merkle Tree Hash", der verhindert, dass Log-Einträge geändert oder gelöscht werden. Wenn sie also einmal eingetragen sind, sind sie für die Öffentlichkeit immer sichtbar. Browser verlangen eventuell SCTs (die anzeigen, dass das Zertifikat öffentlich bekannt gegeben wurde) während der Verarbeitung von SSL-Zertifikaten bei der Einrichtung einer TLS-Sitzung. Diese SCTs sind also ein zunehmend wichtiges Merkmal in der Web-PKI. Mehr dazu später.

Monitore fragen CT-Logs ab und können Zertifikate zum späteren Reporting herunterladen und speichern. Monitore zergliedern die Zertifikate in Teilfelder und erlauben ihren Benutzern, Abfragen für Zertifikate zu erstellen und auszuführen. Domain-Besitzer sind sicherlich daran interessiert, Benachrichtigungen für Zertifikate zu erhalten, die für ihre Domains ausgestellt wurden, oder für Zertifikate, die mit ihrem Unternehmensnamen übereinstimmen. Compliance-Teams achten auf die Einhaltung der CA/Browser Forum Baseline Requirements oder Root-Programm Anforderungen. Unabhängig davon gibt es viele weitere Zwecke für Monitore. Einige Drittanbieter-Dienste haben CT-Monitoring-Tools veröffentlicht oder damit begonnen, sie in bestehende Lösungspakete einzubinden. Facebook hat beispielsweise Ende vergangenen Jahres seinen eigenen kostenlosen Monitoring-Service gestartet.

Was sind Vorzertifikate?
CT-Logs akzeptieren SSL-Vorzertifikate und Zertifikate. Ein Vorzertifikat enthält die gleichen Daten wie das "echte" Zertifikat. Es enthält aber auch eine zusätzliche Erweiterung, die das Zertifikat unbrauchbar macht. Diese Erweiterung wird als "Gifterweiterung" bezeichnet und unterscheidet das Vorzertifikat vom "echten". Alle von einer CA ausgestellten Zertifikate enthalten eindeutige Seriennummern. Das Vorzertifikat und Zertifikat haben aber die gleiche Seriennummer. Deshalb ist es wichtig, eines von beiden ungültig oder nicht nutzbar zu machen.

Wozu sind Vorzertifikate gut?
Es gibt mehrere Methoden für die Bereitstellung von SCTs für die Browser-Verarbeitung.Die zuverlässigste und sinnvollste ist die, SCTs in das Zertifikat einzufügen. Um SCTs vor der Ausstellung zu erhalten (so können sie in das Zertifikat eingefügt werden), muss die CA ein Vorzertifikat erstellen, es in CT-Logs eintragen, SCTs erhalten und sie dann in das endgültige Zertifikat einfügen.
Vor der Ausstellung eines Zertifikats kann eine CA ein Protokoll im CT-Log eintragen, mit der Absicht das entsprechende Zertifikat auszustellen. In der Tat wird die Erstellung und Veröffentlichung eines Vorzertifikats, das nicht ordnungsgemäß validiert oder formatiert ist, als eine Falschausstellung betrachtet.

Wer kann Zertifikate in CT-Logs eintragen?
Jeder kann Zertifikate in CT-Logs eintragen, aber nur CAs tragen Vorzertifikate ein. Suchmaschinen und Website-Betreiber tragen ebenfalls häufig Zertifikate in CT-Logs ein.

Einige CT-Log-Betreiber akzeptieren Zertifikate nur unter bestimmten Roots, einige akzeptieren keine abgelaufenen Zertifikate, und alle Zertifikate (oder Vorzertifikate) müssen als SSL-Zertifikate verwendet werden (d. h. Sie können keine S/MIME- oder Code Signing Zertifikate in CT-Logs eintragen).

Die Verwendung von SCTs
Der SCT - der Nachweis, dass das Zertifikat gelogged wurde - muss dem Webbrowser zur Verfügung gestellt werden um das SSL-Zertifikat ordnungsgemäß zu evaluieren. Das genaue Browserverhalten und die Anforderungen an SCTs variieren je nach Browser. Aber in allen Fällen muss der Browser die SCTs bekommen. Theoretisch könnte auch der Browser beim Erstellen einer TLS-Sitzung SSL-Zertifikate in Logs eintragen um SCTs zu erhalten. Die Kosten wären aber kaum tragbar.

Es gibt im Wesentlichen drei Methoden um dem Browser SCTs zur Verfügung zu stellen:

1. Zertifikatserweiterung
Die am häufigsten verwendete und zuverlässigste Methode für die CA zur Bereitstellung von SCTs an den Browser, ist es, SCTs in das Zertifikat einzufügen. Da der Browser das SSL-Zertifikat braucht, um die TLS-Sitzung herzustellen, ist das Zertifikat garantiert vorhanden und kann immer zum Lesen von SCTs verwendet werden.
Einige Website-Inhaber wollen möglicherweise nicht, dass ihre Website-URL vor dem Start der betreffenden Website bekannt wird. Das wäre gegebenenfalls ein Grund, Zertifikate nicht im Voraus in CT-Logs einzutragen und lieber eine andere Methode zu wählen.
2. TLS (SSL) -Erweiterung
Der Website-Betreiber kann SCTs auch im TLS-Protokoll bereitstellen. In diesem Modell übergibt der Website-Betreiber/Webserver das Zertifikat an die CT-Logs und erhält im Gegenzug die SCTs. Die SCTs sind im TLS-Handshake über eine TLS-Erweiterung unter dem Namen "signed_certificate_timestamp" enthalten. Der "Nachteil" dieser Bereitstellungsmethode ist, dass Webserver-Betreiber ihre Standard-Webserver-Konfigurationen ändern müssen und nicht alle Webserver diese Option unterstützen.

3. OCSP-Stapling
OCSP-Meldungen lassen sich ebenfalls für das Verteilen von SCTs an den Browser verwenden. Dazu müssen zwei Voraussetzungen erfüllt sein:

1.
Der Website-Betreiber muss einen Webserver verwenden, der OCSP-Stapling unterstützt und er muss seinen Server so konfigurieren, dass er eine gültige OCSP-Antwort anfordert und herunterlädt. Geschieht das nicht, gibt es keine Garantie, dass der Browser die OCSP-Nachricht mit den SCTs abruft (viele Browser unterstützen OCSP nicht, sodass dies kein zuverlässiger Bereitstellungsmechanismus ist, es sei denn, die OCSP-Antwort ist im TLS-Protokoll enthalten).

2.
Die CA muss ihren OCSP-Service so konfigurieren, dass er SCT-Stapling unterstützt. Nachdem das Zertifikat ausgestellt wurde, trägt die CA es in mehrere Logs ein und bekommt anschließend die SCTs. Wenn OCSP-Antworten generiert werden, fügt die CA die SCTs zur OCSP-Nachricht hinzu.Damit hat der Browser sowohl den Widerrufstatus als auch die notwendigen SCTs.

Während Methode 2 und 3 eine spezielle Serverkonfiguration erfordern, bieten sie im Vergleich zu Option 1 mehr Flexibilität. Wenn Zertifikat-Logs nicht mehr vertrauenswürdig sind, können Websitebetreiber und die CA die verwendeten Logs dynamisch neu konfigurieren.

Die Google CT-Richtlinie
Um "CT-qualifiziert" zu sein, verlangt Google, dass ein Zertifikat in mehreren Logs erscheint (mindestens ein Google- und ein Nicht-Google-Log). Und die Anzahl der benötigten SCTs hängt vom Gültigkeitszeitraum des Zertifikats ab. Weitere Informationen finden Sie in Googles Certificate Transparency in Chrome.

Was muss ich tun, um CT-konform zu sein?
Sie kennen nun die CT-Grundlagen. Die beste Lösung, um sicherzustellen, dass Sie konform sind, ist, eine CA auszuwählen, die gemäß der Google CT-Richtlinie SCTs zum ausgestellten Zertifikat hinzufügt. Die überwiegende Mehrheit unserer SSL-Zertifikate ist bereits zur Google-Richtlinie konform, in wenigen Monaten sind es alle. Volle fünf Monate vor Ablauf der Google-Frist vom April 2018.

Bisher ist Google der einzige Browser-Anbieter, der Zeitpläne für seine CT-Anforderungen veröffentlicht hat. Mozilla hat zwar auch eine Richtlinie entworfen, allerdings wurden noch keine Termine bekannt gegeben. Sehr wahrscheinlich werden sie mit denen von Google kompatibel sein. (GlobalSign: ra)

eingetragen: 15.10.17
Home & Newsletterlauf: 06.11.17


GlobalSign: Kontakt und Steckbrief

Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.


Meldungen: Grundlagen

  • Zertifikat ist allerdings nicht gleich Zertifikat

    Für Hunderte von Jahren war die Originalunterschrift so etwas wie der De-facto-Standard um unterschiedlichste Vertragsdokumente und Vereinbarungen aller Art rechtskräftig zu unterzeichnen. Vor inzwischen mehr als einem Jahrzehnt verlagerten sich immer mehr Geschäftstätigkeiten und mit ihnen die zugehörigen Prozesse ins Internet. Es hat zwar eine Weile gedauert, aber mit dem Zeitalter der digitalen Transformation beginnen handgeschriebene Unterschriften auf papierbasierten Dokumenten zunehmend zu verschwinden und digitale Signaturen werden weltweit mehr und mehr akzeptiert.

  • Datensicherheit und -kontrolle mit CASBs

    Egal ob Start-up oder Konzern: Collaboration Tools sind auch in deutschen Unternehmen überaus beliebt. Sie lassen sich besonders leicht in individuelle Workflows integrieren und sind auf verschiedenen Endgeräten nutzbar. Zu den weltweit meistgenutzten Collaboration Tools gehört derzeit Slack. Die Cloudanwendung stellt allerdings eine Herausforderung für die Datensicherheit dar, die nur mit speziellen Cloud Security-Lösungen zuverlässig bewältigt werden kann. In wenigen Jahren hat sich Slack von einer relativ unbekannten Cloud-Anwendung zu einer der beliebtesten Team Collaboration-Lösungen der Welt entwickelt. Ihr Siegeszug in den meisten Unternehmen beginnt häufig mit einem Dasein als Schatten-Anwendung, die zunächst nur von einzelnen unternehmensinternen Arbeitsgruppen genutzt wird. Von dort aus entwickelt sie sich in der Regel schnell zum beliebtesten Collaboration-Tool in der gesamten Organisation.

  • KI: Neue Spielregeln für IT-Sicherheit

    Gerade in jüngster Zeit haben automatisierte Phishing-Angriffe relativ plötzlich stark zugenommen. Dank künstlicher Intelligenz (KI), maschinellem Lernen und Big Data sind die Inhalte deutlich überzeugender und die Angriffsmethodik überaus präzise. Mit traditionellen Phishing-Angriffen haben die Attacken nicht mehr viel gemein. Während IT-Verantwortliche KI einsetzen, um Sicherheit auf die nächste Stufe zu bringen, darf man sich getrost fragen, was passiert, wenn diese Technologie in die falschen Hände, die der Bad Guys, gerät? Die Weiterentwicklung des Internets und die Fortschritte beim Computing haben uns in die Lage versetzt auch für komplexe Probleme exakte Lösungen zu finden. Von der Astrophysik über biologische Systeme bis hin zu Automatisierung und Präzision. Allerdings sind alle diese Systeme inhärent anfällig für Cyber-Bedrohungen. Gerade in unserer schnelllebigen Welt, in der Innovationen im kommen und gehen muss Cybersicherheit weiterhin im Vordergrund stehen. Insbesondere was die durch das Internet der Dinge (IoT) erzeugte Datenflut anbelangt. Beim Identifizieren von Malware hat man sich in hohem Maße darauf verlassen, bestimmte Dateisignaturen zu erkennen. Oder auf regelbasierte Systeme die Netzwerkanomalitäten aufdecken.

  • DDoS-Angriffe nehmen weiter Fahrt auf

    DDoS-Attacken nehmen in Anzahl und Dauer deutlich zu, sie werden komplexer und raffinierter. Darauf machen die IT-Sicherheitsexperten der PSW Group unter Berufung auf den Lagebericht zur IT-Sicherheit 2018 des Bundesamtes für Sicherheit in der Informationstechnik (BSI) aufmerksam. Demnach gehörten DDoS-Attacken 2017 und 2018 zu den häufigsten beobachteten Sicherheitsvorfällen. Im dritten Quartal 2018 hat sich das durchschnittliche DDoS-Angriffsvolumen im Vergleich zum ersten Quartal mehr als verdoppelt. Durchschnittlich 175 Angriffen pro Tag wurden zwischen Juli und September 2018 gestartet. Die Opfer waren vor allem Service-Provider in Deutschland, in Österreich und in der Schweiz: 87 Prozent aller Provider wurden 2018 angegriffen. Und bereits für das 1. Quartal dieses Jahres registrierte Link11 schon 11.177 DDoS-Angriffe.

  • Fluch und Segen des Darkwebs

    Strengere Gesetzesnormen für Betreiber von Internet-Plattformen, die Straftaten ermöglichen und zugangsbeschränkt sind - das forderte das BMI in einem in Q1 2019 eingebrachten Gesetzesantrag. Was zunächst durchweg positiv klingt, wird vor allem von Seiten der Bundesdatenschützer scharf kritisiert. Denn hinter dieser Forderung verbirgt sich mehr als nur das Verbot von Webseiten, die ein Tummelplatz für illegale Aktivitäten sind. Auch Darkweb-Plattformen, die lediglich unzugänglichen und anonymen Speicherplatz zur Verfügung stellen, unterlägen der Verordnung. Da diese nicht nur von kriminellen Akteuren genutzt werden, sehen Kritiker in dem Gesetzesentwurf einen starken Eingriff in die bürgerlichen Rechte. Aber welche Rolle spielt das Darkweb grundsätzlich? Und wie wird sich das "verborgene Netz" in Zukunft weiterentwickeln? Sivan Nir, Threat Analysis Team Leader bei Skybox Security, äußert sich zu den zwei Gesichtern des Darkwebs und seiner Zukunft.