Zertifikatstransparenz - Certificate Transparency

Zertifikatstransparenz ( CT ) ist ein Internet - Sicherheitsstandard und Open - Source - Framework für die Überwachung und Prüfung von digitalen Zertifikaten . Der Standard erstellt ein System öffentlicher Protokolle , das versucht, alle von öffentlich vertrauenswürdigen Zertifizierungsstellen ausgestellten Zertifikate aufzuzeichnen , um eine effiziente Identifizierung irrtümlich oder böswillig ausgestellter Zertifikate zu ermöglichen.

Zertifikatstransparenz wird in einem experimentellen RFC  6962 beschrieben .

Ab 2021 ist die Zertifikatstransparenz für alle TLS- Zertifikate obligatorisch , jedoch nicht für andere Zertifikatstypen.

Hintergrund

Im Jahr 2011, ein Wiederverkäufer von der Zertifizierungsstelle Comodo wurde angegriffen und die Zertifizierungsstelle DigiNotar wurde beeinträchtigt , Aufmerksamkeit in der Zertifizierungsstelle Ökosystem vorhandenen Mängel forderte und arbeitet auf verschiedenen Mechanismen zu beschleunigen , zu verhindern oder nicht autorisierte Zertifikatsausgabe zu überwachen. Ben Laurie , Adam Langley und Emilia Kasper begannen im selben Jahr mit der Arbeit an einem Open-Source- Framework , um diese Probleme zu bekämpfen. Den ersten Entwurf des Standards legten sie 2012 als IETF Internet Draft unter dem Codenamen „Sunlight“ vor.

Vorteile

Eines der Probleme bei der Verwaltung digitaler Zertifikate besteht darin, dass es lange dauert, bis betrügerische Zertifikate von den Browser-Herstellern erkannt, gemeldet und widerrufen werden. Zertifikatstransparenz würde dabei helfen, die Ausstellung eines Zertifikats für eine Domain ohne Wissen des Domaininhabers unmöglich zu machen.

Zertifikattransparenz erfordert keine Seitenkanalkommunikation, um Zertifikate zu validieren, wie dies bei einigen konkurrierenden Technologien wie dem Online Certificate Status Protocol (OCSP) und Convergence der Fall ist .

Protokolle zur Zertifikatstransparenz

Die Zertifikatstransparenz hängt von überprüfbaren Zertifikatstransparenzprotokollen ab. Ein Protokoll hängt neue Zertifikate an einen ständig wachsenden Merkle-Hash-Baum an . Damit sich ein Protokoll korrekt verhält, muss es:

  • Stellen Sie sicher, dass jedes eingereichte Zertifikat oder Vorzertifikat über eine gültige Signaturkette verfügt, die zu einem vertrauenswürdigen Stammzertifizierungsstellenzertifikat zurückführt.
  • Verweigern Sie die Veröffentlichung von Zertifikaten ohne diese gültige Signaturkette.
  • Speichern Sie die gesamte Verifizierungskette vom neu akzeptierten Zertifikat zurück zum Stammzertifikat.
  • Legen Sie diese Kette auf Anfrage zur Prüfung vor.

Ein Protokoll kann Zertifikate akzeptieren, die noch nicht vollständig gültig sind, und Zertifikate, die abgelaufen sind.

Zertifikatstransparenzmonitore

Monitore fungieren als Clients für die Protokollserver. Monitore überprüfen Protokolle, um sicherzustellen, dass sie sich richtig verhalten. Eine Inkonsistenz wird verwendet, um zu beweisen, dass sich ein Protokoll nicht korrekt verhalten hat, und die Signaturen in der Datenstruktur des Protokolls (der Merkle-Baum) verhindern, dass das Protokoll dieses Fehlverhalten leugnen kann.

Zertifikatstransparenz-Auditoren

Auditoren fungieren auch als Clients für die Protokollserver. Zertifikatstransparenzprüfer verwenden Teilinformationen zu einem Protokoll, um das Protokoll mit anderen Teilinformationen zu vergleichen, über die sie verfügen.

Protokollprogramme zur Zertifikatstransparenz

Apple und Google haben separate Protokollprogramme mit unterschiedlichen Richtlinien und Listen vertrauenswürdiger Protokolle.

Stammspeicher von Zertifikatstransparenzprotokollen

Zertifikattransparenzprotokolle verwalten ihre eigenen Root-Speicher und akzeptieren nur Zertifikate, die zu den vertrauenswürdigen Roots verkettet sind. In der Vergangenheit wurden in einer Reihe von fehlerhaften Protokollen inkonsistente Root-Speicher veröffentlicht.

Geschichte

Ein Beispiel für den Eintrag zur Zertifikatstransparenz in Firefox 89

Im März 2013 hat Google sein erstes Zertifikatstransparenzprotokoll veröffentlicht. Im September 2013 hat DigiCert als erste Zertifizierungsstelle Certificate Transparency implementiert.

Seit 2015 verlangt Google Chrome Zertifikatstransparenz für neu ausgestellte Extended Validation Certificates . Ab dem 1. Juni 2016 wurde für alle von Symantec neu ausgestellten Zertifikate Zertifikatstransparenz verlangt , nachdem festgestellt wurde, dass sie ohne Wissen der Domaininhaber 187 Zertifikate ausgestellt hatten. Seit April 2018 wird diese Anforderung auf alle Zertifikate ausgeweitet.

Am 23. März 2018 kündigte Cloudflare sein eigenes CT-Log namens Nimbus an .

Im März 2018 wurde der Entwurf "Certificate Transparency Version 2.0" veröffentlicht.

Im Mai 2019 hat die Zertifizierungsstelle Let's Encrypt ihr eigenes CT-Protokoll namens Oak veröffentlicht. Seit Februar 2020 ist es in genehmigten Log-Listen enthalten und kann von allen öffentlich vertrauenswürdigen Zertifizierungsstellen verwendet werden.

Signaturalgorithmen

Derzeit muss ein Protokoll NIST P-256- Kurve oder RSA- Signaturen verwenden (mit einem Schlüssel von mindestens 2048 Bit). :Abschnitt 2.1.4

Wenn der Standard Certificate Transparency Version 2.0 veröffentlicht wird, sind die zulässigen Algorithmen NIST P-256, Deterministic ECDSA oder Ed25519 .

Tools zur Inspektion von CT-Protokollen

Verweise

Externe Links