Schlagwort-Archive: Certificate Transparency

Überwachen der Zertifikate zu eigenen Domains mit Certificate Transparency

[Update 21.01.2021: Hinweise zu Limitierungen bei der Ergebnisgröße; showSQL=Y]

Certificate Transparency ist ein seit einigen Jahren etablierter Mechanismus, um die in der sog.  Web-PKI verwendeten Zertifikate sichtbar zu machen.

Kern des Systems sind öffentlich zugängliche Certificate Transparency Logs, die von Organisationen wie Google, Cloudflare oder kommerziellen CAs betrieben werden. In diese Logs wird üblicherweise direkt bei Erstellung eines Zertifikats ein sogenanntes „Precertificate“ mit allen relevanten Daten geschrieben und öffentlich wieder abrufbar gemacht. Aktuell gibt es 30 Logs, die vom Chrome-Browser akzeptiert werden: https://www.certificate-transparency.org/known-logs

Die DFN-PKI nutzt dieses System seit 2018, siehe auch https://blog.pki.dfn.de/2018/01/certificate-transparency-in-der-dfn-pki/

Inzwischen ist davon auszugehen, das praktisch jedes weltweit ausgestellte Serverzertifikat mit Browser-Verankerung  in den Logs erscheinen wird. Dies kann man sich zunutze machen, um neu ausgestellte Zertifikate für die eigene Domain zu überwachen. Dies kann z.B. für die folgenden Zwecke geschehen:

  • Weitere Datenbasis für das Organisations-eigene Zertifikatmanagement
  • Schnelle Erkennung von fälschlich oder betrügerisch ausgestellten Zertifikaten, z.B. durch eigene Fehler oder Fehler/Schwachstellen bei der CA  (Bedingung: Die Mechanismen der CA zum Schreiben in die CT Logs wurden vom Angreifer nicht überwunden)
  • Zentrales Monitoring über die in der Organisation eingesetzten CAs
  • Erkennen von zusätzlichen Zertifikaten im Zusammenhang mit CDN- oder Cloud-Diensten

Zertifikate aus internen CAs, die nicht per Default im Browser oder Betriebssystem als vertrauenswürdig erscheinen, werden mit Certificate Transparency nicht erfasst.

Inzwischen gibt es einige Angebote, die Certificate Transparency Logs abfragen, die Informationen aufbereiten und zur Verfügung stellen, beispielsweise von Censys.io, Cloudflare,  sslmate, Sectigo (crt.sh), Google und Facebook (teilweise auch kostenpflichtig).

Prinzipiell ist es möglich, die 30 Certificate Transparency Logs direkt selbst zu untersuchen. Mit certspotter steht hierfür sogar eine fertige Software zur Verfügung: https://github.com/SSLMate/certspotter

Leider ist hierfür ein relativ hoher betrieblicher Aufwand notwendig: Aufgrund der Menge der weltweit ausgestellten Serverzertifikate kann der Ressourcen-Bedarf von certspotter, insbesondere in Bezug auf die nötige Bandbreite, beträchtlich sein. Schlimmer noch: Einige der Logs wachsen um mehrere hundert Zertifikate pro Sekunde, liefern mitunter aber nicht in entsprechender Rate aus, so dass es teilweise gar nicht möglich ist, die im Log vorhandenen Zertifikate kontinuierlich zu monitoren.

crt.sh

Ein anderer Weg macht sich den Dienst von https://crt.sh zu nutze. crt.sh fragt kontinuierlich alle relevanten CT Logs ab, und bereitet die Daten in einer leicht konsumierbaren Form auf. Der Dienst wird von Sectigo, einem CA-Anbieter, betrieben, und ist öffentlich zugänglich.

crt.sh bietet ein einfaches API an, um zu einer Domain ausgestellte Zertifikate zu erhalten. Die Ergebnisse werden auf Wunsch als JSON zurückgegeben.

Abfrage (unter Ausschluss von abgelaufenen Zertifikaten):
https://crt.sh/?q=%.example.org&exclude=expired&output=json

Ausgabe:

[{"issuer_ca_id":185756,"issuer_name":"C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1",
"common_name":"www.example.org",
"name_value":"example.org\nwww.example.org,
"id":3704614715,
"entry_timestamp":"2020-11-27T13:49:06.706",
"not_before":"2020-11-24T00:00:00","not_after":"2021-12-25T23:59:59",
"serial_number":"0fbe08b0854d05738ab0cce1c9afeec9"},
....

Mit Hilfe des Eintrags "id" aus der Ausgabe kann das entspr. Zertifikat mit der Abfrage https://crt.sh/?id=<Wert von id> direkt betrachtet werden, z.B. https://crt.sh/?id=3704614715

Großer Nachteil dieser Lösung: Die Anzahl der zurückgelieferten Zertifikate ist limitiert. Daher können auf diesem Wege nur Domains oder Subdomains mit weniger als ca. 1000 Zertifikaten überwacht werden.

Es gibt keine Möglichkeit, das Ergebnis auf einen bestimmten Zeitraum einzuschränken. Für eine eigene Monitoring-Lösung muss man also eine eigene Datenbank mit bereits bekannten Zertifikaten aufbauen, und die Ergebnisse gegen diese abgleichen.

crt.sh ist ein sehr belasteter Dienst, und es kommt gelegentlich vor, dass eine Abfrage mit einem HTTP Status 502 abbricht. In diesem Fall empfiehlt sich eine kleine Wartezeit und ein erneuter Versuch.

„leaf certificate“ und „Precertificate“

Häufig wird man zu einem existierenden Zertifikat zwei Einträge finden. Im o.g. Beispiel:
https://crt.sh/?id=3692510597
https://crt.sh/?id=3704614715

Die beiden Einträge meinen das gleiche Zertifikat mit identischen Daten und identischer Seriennummer, aber einmal als normales „leaf certificate“ und einmal als „Precertificate“ (Zeile „Summary“ ganz am Anfang der Darstellung bei crt.sh). Dies ist nicht ungewöhnlich und kein Grund zur Sorge. Ein Precertificate ist, grob gesagt, ein Artefakt mit dem die CA vor der Ausstellung des korrekten „echten“ Zertifikats einen Beweis für die Aufnahme in CT Logs generieren kann. Eine genauere Beschreibung von Precertificates findet sich in Kapitel 3.1 des RFC: https://tools.ietf.org/html/rfc6962#section-3.1

Fügt man zur Abfrage den Parameter deduplicate=Y hinzu, erhält man nicht mehr sowohl leaf als auch Precertificate in der Ausgabe.

crt.sh Datenbank

Neben der Abfrage per HTTP ist auch die zugrunde liegende postgresql-Datenbank von crt.sh direkt ansprechbar:

$ psql -h crt.sh -p 5432 -U guest certwatch

Eine Beispiel-Abfrage zum Abruf der nicht abgelaufenen Zertifikate der Domain example.org (Quelle):

SELECT ci.ISSUER_CA_ID,
        ca.NAME ISSUER_NAME,
        ci.NAME_VALUE NAME_VALUE,
        min(c.ID) MIN_CERT_ID,
        min(ctle.ENTRY_TIMESTAMP) MIN_ENTRY_TIMESTAMP,
        x509_notBefore(c.CERTIFICATE) NOT_BEFORE,
        x509_notAfter(c.CERTIFICATE) NOT_AFTER
    FROM ca,
        ct_log_entry ctle,
        certificate_identity ci,
        certificate c
    WHERE ci.ISSUER_CA_ID = ca.ID
        AND c.ID = ctle.CERTIFICATE_ID
        AND reverse(lower(ci.NAME_VALUE)) LIKE reverse(lower('%.example.org'))
        AND ci.CERTIFICATE_ID = c.ID
        AND x509_notAfter(c.CERTIFICATE) > statement_timestamp()
    GROUP BY c.ID, ci.ISSUER_CA_ID, ISSUER_NAME, NAME_VALUE, c.CERTIFICATE
    ORDER BY MIN_ENTRY_TIMESTAMP DESC, NAME_VALUE, ISSUER_NAME;

Die Datenbank ist allerdings durchaus nicht-trivial. Viele Daten sind nicht als gewöhnliche Spalten verfügbar, sondern müssen über Funktionen abgefragt werden. Auch die postgresql-Datenbank ist hoch belastet; Verbindungsfehler oder Timeouts sind nicht ungewöhnlich.

showSQL=Y

Um eine Ausgangsbasis für mögliche Abfragen in der Datenbank zu erhalten, kann man wieder die Webseite https://crt.sh verwenden: Fügt man an das Ende einer Suche den Parameter showSQL=Y an, zeigt crt.sh die zugehörige Datenbankabfrage.

Beispiel:

https://crt.sh/?dNSName=%25.example.org&exclude=expired&deduplication=Y&showSQL=Y

(Jürgen Brauckmann, 11.01.2021)

Certificate Transparency in der DFN-PKI

Als Konsequenz aus Problemen mit den Zertifizierungsprozessen bei einigen CAs, die in den letzten Jahren offenbar wurden, haben Forscher u.a. von Google ein System namens Certificate Transparency (CT) entwickelt.

Hierbei handelt es sich um einen Mechanismus, mit dem ausgestellte Serverzertifikate von einer oder mehreren Sammelpunkten öffentlich einsehbar gehalten werden. Ziel ist die Erhöhung der Transparenz der Browser-PKI durch die komplette Überprüfbarkeit der CAs durch die Öffentlichkeit.

Diese Sammelpunkte sind die Kernkomponenten des Certificate Transparency Systems, sie werden als Certificate Transparency Logs (CT-Logs) bezeichnet und von beliebigen Parteien betrieben. Über kryptographische Beweise (Consistency Proofs über Merkle Hash Trees) ist sichergestellt, dass Außenstehende eine nachträgliche Manipulation des CT-Logs bemerken können.

Einen technischen Überblick über die Funktionsweise bietet https://www.certificate-transparency.org

Weitere Erläuterungen finden sich in folgendem Golem-Artikel (die dort dargestellte Timeline von Google Chrome ist allerdings überholt): https://www.golem.de/news/certificate-transparency-betrug-mit-tsl-zertifikaten-wird-fast-unmoeglich-1610-124024.html

Praktischer Einsatz

Google hat angekündigt, dass sein Browser Chrome ab Frühjahr 2018 erzwingen wird, dass neu ausgestellte Serverzertifikate der öffentlichen Browser-PKI in CT-Logs veröffentlicht werden. Chrome setzt dies um, indem beim TLS-Verbindungsaufbau das Vorhandensein von mehreren sogenannten Signed Certificate Timestamps (SCTs), kryptographisch gesicherte Artefakte von der Veröffentlichung eines Zertifikats, geprüft wird. Können von Chrome keine SCTs geprüft werden, wird die Webseite als unsicher klassifiziert, wobei die genaue Art der Darstellung in Chrome noch unbekannt ist.

Es gehört inzwischen zu den Qualitätsmerkmalen einer PKI, am Certificate Transparency System teilzunehmen und ausgestellte Serverzertifikate über CT-Logs verfügbar zu machen. Auch die DFN-PKI wird selbstverständlich Certificate Transparency unterstützen. Ab 26.02.2018 werden alle Serverzertifikate in der DFN-PKI Sicherheitsniveau Global in CT-Logs veröffentlicht.

Wichtig: Es gibt keine Auswirkungen auf bereits ausgestellte Serverzertifikate! Diese sind nicht betroffen, bleiben nach unserem Kenntnisstand auch in Google Chrome voll gültig und müssen nicht ausgetauscht werden.

Die DFN-PKI wird die folgenden CT-Logs verwenden:
https://plausible.ct.nordu.net
https://mammoth.ct.comodo.com
https://sabre.ct.comodo.com
https://ct.googleapis.com/rocketeer
https://ct.googleapis.com/pilot

(Diese Liste stellt den aktuellen Stand vom Februar 2018 dar. Die von der DFN-PKI verwendeten CT-Logs können sich kurzfristig und ohne Vorankündigung ändern. Zertifikate aus der DFN-PKI können über Uploads von Dritten auch in anderen als den aufgeführten CT-Logs erscheinen. Eine aktuelle Liste ist erhältlich über https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c19130)

Auslieferung von SCTs

Die DFN-PKI stellt die oben erwähnten notwendigen Signed Certificate Timestamps direkt als Erweiterung in den ausgestellten Serverzertifikaten zur Verfügung („Embedded SCT“). Ein Beispiel mit eingebetteten SCTs finden Sie unter: https://crt.sh/?id=313019897

Grundsätzlich gibt es im Certificate Transparency System noch weitere Möglichkeiten, wie die SCTs einem Browser zugänglich gemacht werden können („OCSP Stapling“, „TLS Extension“). Diese anderen Varianten setzen aber üblicherweise Konfigurationseingriffe des Serveradministrators voraus.

Durch die von der DFN-PKI gewählte Variante der Embedded SCT müssen Serveradministratoren keine Änderungen an ihrem System vornehmen.

Zustimmung zur Veröffentlichung

Neben der rein technischen Anbindung, die von der DFN-PKI in den letzten Monaten umgesetzt worden ist, ergibt sich eine Änderung für Antragssteller: Wird ein Serverzertifikat in der DFN-PKI im Sicherheitsniveau Global beantragt, so muss in Zukunft der Antragssteller der Veröffentlichung zustimmen. Ohne diese Zustimmung wird in der DFN-PKI in Zukunft kein Serverzertifikat mehr erstellt werden können.

Des Weiteren ist eine Rücknahme dieser Zustimmung nicht mehr möglich. Technischer Hintergrund: Ein einmal mit Certificate Transparency veröffentlichtes Zertifikat kann technisch nicht mehr „depubliziert“ werden.

Nutzerzertifikate sind selbstverständlich von dieser Änderung nicht betroffen und werden generell nicht durch die DFN-PKI in den CT-Logs veröffentlicht. Je nach Grundeinstellung Ihres PKI-Zugangs sind auch weiterhin nicht-öffentliche Nutzerzertifikate möglich, die damit dann auch nicht über die von der DFN-PKI selbst betriebenen Verzeichnisdienste (LDAP und Web-Suche) veröffentlicht werden. Die gesetzlich vorgeschriebenen Widerrufsmöglichkeiten werden für Nutzerzertifikate natürlich ebenfalls vollumfänglich angeboten.

 (jbr, 30.01.2018)