- 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

- Anzeigen -





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.

- Anzeigen -





Kostenloser IT SecCity-Newsletter
Ihr IT SecCity-Newsletter hier >>>>>>

- Anzeigen -


Meldungen: Grundlagen

  • Sieben Punkte zur IoT-Security

    Das Internet der Dinge steckt immer noch in den Kinderschuhen, aber hat sich bereits einen Ruf als ausgewachsenes Sicherheitsrisiko gemacht. Ob Router, Drucker, Smart-TV, Spielzeug oder Waschmaschinen - vernetzte Geräte werden für Cyberkriminelle zum Werkzeug für illegales Krypto-Mining, DDoS-Angriffe bis hin zur Lösegelderpressung durch angedrohte Datenlöschung, wie im Fall des Spielzeugherstellers Spiral Toys. Dessen Datenleck machte 2017 Schlagzeilen, bei dem mehr als 800.000 Nutzer betroffen waren. Die IoT-Malware-Landschaft entwickelt sich stetig weiter, während die Sicherheitsvorkehrungen meist noch rudimentär sind. Das Anfang des Jahres entdeckte Botnet "Hide and Seek" bettet, im Gegensatz zur berüchtigten DDoS-Mirai-Malware, eine Vielzahl von Befehlen wie Datenexfiltration, Code-Ausführung und Interferenz mit dem Betrieb des Geräts ein. Die Sicherheitsrisiken im IoT-Bereich sind Großteils auf das rasante Tempo zurückzuführen, mit dem IoT-Devices weltweit implementiert werden - 20 Milliarden installierte Geräte sind nach Schätzungen von Gartner bis Ende 2020 zu erwarten. Im hart umkämpften Technologiesektor hat der Eifer, als erster mit erschwinglichen IoT-Geräten auf den Markt zu kommen, dazu geführt, dass viele Hersteller selbst einige der grundlegendsten Sicherheitsprinzipien zugunsten schneller Entwicklungszyklen außer Acht gelassen haben.

  • Implementierung einer Public Key Infrastructure

    Die digitale Transformation hat inzwischen eine Vielzahl von Branchen erreicht. Nicht zuletzt angetrieben durch die rasante Weiterentwicklung des Internet of Things (IoT) und die darin liegenden unternehmerischen Möglichkeiten. Wie etwa den, sich Wettbewerbsvorteile gegenüber der Konkurrenz zu verschaffen. Richtig aufgesetzt haben IoT-Projekte das Potenzial, betriebliche Abläufe zu rationalisieren, neue Umsatzquellen zu erschließen und Dienstleistungen besser auf die Bedürfnisse der Kunden zuzuschneiden. So erheben und sammeln IoT-Geräte Unmengen von Daten, die Firmen analysieren und für sich nutzbar machen können. Dazu muss allerdings eines gewährleistet sein: Sowohl die Geräte als auch die Daten müssen vertrauenswürdig sein. Sonst hätte es wenig Sinn, sie aufwendig zu analysieren und zueinander in Beziehung zu setzen. Will man die ambitionierten Ziele der digitalen Transformation erreichen, braucht es zwingend eine Vertrauensbasis für IoT-Anwendungen. Eine Technologie, die sich in dieser Hinsicht bereits bewährt hat, wird hier zu einem der zentralen Bausteine: eine auf Best Practices basierende Public Key Infrastructure (PKI).

  • KI: Kein Ersatz für IT-Sicherheitsteams

    Ob Spear-Phishing, Ransomware oder Zero-Day-Exploits, Netzwerke sind ständig in Gefahr gehackt zu werden. Die wachsende Bedrohung geht einher mit immer komplexeren IT-Landschaften, mehr Daten und weniger IT-Personal. Um ihre Netzwerke unter diesen schwierigen Umständen effektiver zu schützen, setzen viele Unternehmen inzwischen auf Technologien wie KI-basierte Verhaltensüberwachung. Sie nutzt die Möglichkeiten von Datenanalyse und maschinellem Lernen um einen der größten Risikofaktoren im Netzwerk zu minimieren: den Benutzer. Nutzer sind die Einfallstore, die sensible Unternehmensdaten gefährden, sei es ein kompromittiertes Nutzerkonto im Netzwerk, ein Insider-Angriff oder unbedachtes Verhalten eines Mitarbeiters.

  • Cyber-Erpressung auf Bestellung

    CryptoLocker, GoldenEye, Locky, WannaCry - Ransomware hat mit der Geiselnahme von Dateien durch Verschlüsselung in den letzten Jahren eine beachtliche und unrühmliche Karriere hingelegt. Und da sich Kriminelle auch bei Digitalisierungstrends wie as-a-Service-Angeboten nicht lumpen lassen, hat die Untergrundökonomie mit Ransomware-as-a-Service (RaaS) rasch ein lukratives Geschäftsmodell für sich entdeckt, das in kürzester Zeit enormes Wachstum erlebt hat. Das Prinzip ist denkbar einfach - wie in der legalen Wirtschaft sind die Dienstleistungen ganz auf die Bedürfnisse einer möglichst breiten Kundschaft zugeschnitten: Auf Ransomware-as-a-Service-Plattformen können nun auch technisch wenig versierte Kriminelle ins Cyber-Erpressergeschäft einsteigen und sich von Schadware-Entwicklern die entsprechende Service-Leistung gegen Abgabe einer festen Gebühr oder einer Provision basierend auf den Lösegeldeinnahmen besorgen.

  • Investitionen in IT-Sicherheit legitimieren

    Wenn man so oft direkt mit unterschiedlichen Unternehmen und Menschen zu tun hat wie der Vertrieb, erkennt man schnell bestimmte Reaktionsschemata. Ebenso wie zuverlässig wiederkehrende Schwierigkeiten beim Implementieren von IT-Sicherheitsmaßnahmen. Den größten Teil unserer Zeit verbringen wir damit zu erläutern warum Cybersicherheit derart wichtig ist und wie ein Unternehmen von bestimmten Maßnahmen am besten profitiert. Trotzdem erhält man regelmäßig dieselben Antworten: "Ich verstehe absolut wovon Sie sprechen, und ich gebe Ihnen sogar Recht. Nur, wie soll ich die zusätzlichen Ausgaben gegenüber der Geschäftsleitung rechtfertigen?" Es gibt allerdings einige grundlegende Argumente die Kunden helfen, Sicherheitsansätze und Lösungen gegenüber der Geschäftsführung oder anderen Zeichnungsbefugten plausibel zu machen.