Wie sich die Entfernung von Entrust aus dem Root Store von Chrome auf das Internet auswirken wird

Einführung

HTTPS und Zertifizierungsstellen

Einer der Grundpfeiler des modernen Internets ist, dass die Verbindung zwischen Ihrem Computer und Ihrer bevorzugten Website unglaublich sicher ist, zumindest was den zugrunde liegenden Datenverkehr betrifft. Keine Person oder Organisation kann Ihre Internetgewohnheiten ausspähen, indem sie den Datenverkehr zwischen Ihrem Computer und der von Ihnen besuchten Website beobachtet. All dies ist für den Endnutzer transparent. Die zugrundeliegenden Technologien sind jedoch fortschrittlich und hängen von der Definition von Vertrauenskreisen und einer Public-Key-Infrastruktur ab.

Die Rolle von SSL/TLS-Zertifikaten

Wenn Ihr Unternehmen, FooBar, Inc., die Domäne foobar.com besitzt und möchte, dass sich die Benutzer bei der Interaktion mit Ihren Online-Widgets sicher fühlen, würden Sie ein SSL/TLS-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) erwerben. Nach der Installation des Zertifikats auf Ihrem Webserver kann Ihre Website den Benutzern einen HTTPS-Dienst anbieten. Dadurch wird sichergestellt, dass Betriebssysteme und Webbrowser überprüfen können, ob es sich bei der Website, mit der sie kommunizieren, tatsächlich um foobar.com und nicht um einen Betrüger handelt.

Vertrauen und Verifizierung

Technisch gesehen kann jeder ein TLS-Zertifikat für eine beliebige Domäne erstellen und es in seiner Infrastruktur einrichten. Wenn das Zertifikat jedoch nicht von einer anerkannten und vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt und von dieser überprüft wurde, werden Browser und Betriebssysteme jeden Versuch, dieses Zertifikat zu verwenden, mit Sicherheitswarnungen kennzeichnen und die Benutzer vom weiteren Vorgehen abhalten.

Eine vertrauenswürdige CA werden

Der Betrieb als CA bedeutet, dass Sie Zertifikate ausstellen, denen das Internet im Allgemeinen vertraut. Dazu muss Ihr Stammzertifikat von großen Organisationen und Anbietern anerkannt werden, die eine Datenbank mit vertrauenswürdigen Stammzertifizierungsstellen unterhalten. Zumindest müssen Sie von Google, Mozilla, Apple und Microsoft als vertrauenswürdig eingestuft werden, was einen enormen Aufwand bedeutet.

Konformität und Zertifizierung

Um von einem dieser Dachverbände berücksichtigt zu werden, müssen Sie ein wahres Spießrutenlaufen von Prüfungen und Zertifizierungen durchlaufen. Jede Dachorganisation hat ihre eigenen Mindestanforderungen:

• Google Chrome
• Mozilla (Firefox, Thunderbird, etc..)
• Apple (Safari, MacOS, etc...)
• Microsoft (Edge, Windows, etc....)

Die Einhaltung dieser Standards ist keine einmalige Anstrengung, sondern ein kontinuierlicher Prozess, um das Vertrauen der Root-Store-Betreiber und der Internet-Community zu erhalten. Dazu gehört auch, dass auf alle Vorfälle öffentlich reagiert wird, unabhängig davon, ob sie intern entdeckt oder von der Community gemeldet wurden. Sowohl Google als auch Mozilla verlangen von einer vertrauenswürdigen Zertifizierungsstelle, dass sie Vorfälle mit Bugzilla offenlegt und öffentlich darauf reagiert.

"Teilnehmer des Chrome Root-Programms MÜSSEN Berichte über Vorfälle in Bugzilla öffentlich machen und/oder darauf reagieren, unabhängig von den wahrgenommenen Auswirkungen." - Google.

"Zumindest MÜSSEN die Betreiber von CAs alle Vorfälle unverzüglich in Form eines Vorfallsberichts an Mozilla melden". - Mozilla.

Die Entscheidung von Google, Entrust zu entfernen

Entrust ist ein privates Software- und Hardwareunternehmen, das seit 1997 SSL-Zertifikate ausstellt. Der genaue Anteil ihres Geschäfts, der vom Markt für SSL-Zertifikate abhängt, ist zwar unklar, aber es ist bekannt, dass ein erheblicher Teil der Finanzbranche ausschließlich von den von Entrust ausgestellten Zertifikaten abhängig ist

In einer Ankündigung erklärte Google , dass Entrust die Erwartungen an die Einhaltung von Sicherheitsstandards nicht mehr erfüllt. Infolgedessen beschloss Google, dass den Zertifikaten mehrerer Entrust-Root-CAs bei allen nach dem 31. Oktober 2024 ausgestellten Zertifikaten standardmäßig nicht mehr vertraut werden soll.

"TLS-Server-Authentifizierungszertifikate, die auf die folgenden Entrust-Wurzeln validiert sind und deren frühester signierter Zertifikatszeitstempel (SCT) nach dem 31. Oktober 2024 datiert ist, werden standardmäßig nicht mehr als vertrauenswürdig eingestuft."

• CN=Entrust Root Certification Authority - EC1
• CN=Entrust Root Certification Authority - G2
• CN=Entrust.net Zertifizierungsstelle (2048)
• CN=Entrust Root Certification Authority
• CN=Entrust Root Certification Authority - G4
• CN=AffirmTrust Commercial
• CN=AffirmTrust Networking
• CN=AffirmTrust Premium
• CN=AffirmTrust Premium ECC

Diese Änderung bedeutet, dass Chrome neuen Zertifikaten, die von diesen Entrust Root CAs ausgestellt wurden, nach dem angegebenen Datum nicht mehr vertraut. Vorhandene Zertifikate funktionieren weiterhin, bis sie ablaufen oder widerrufen werden.

Der Hauptgrund dafür scheint darin zu liegen, dass Google die mangelnde Kommunikation von Entrust im Zusammenhang mit Vorfallsberichten bemängelt; allerdings wurden keine detaillierten Angaben zu den spezifischen Gründen gemacht, aber wir können vielleicht einige Einblicke gewinnen, wenn wir uns einige frühere Probleme von Entrust ansehen. Im nächsten Abschnitt werden wir auf den Fehlerbericht/Vorfall eingehen, der den Ausschlag für Googles Entscheidung gegeben zu haben scheint, Entrust aus dem Chrome-Root-Zertifikatspeicher zu entfernen.

Das ungebrochene Vertrauen von Entrust

Der Bericht: BUGZILLA ISSUE #1883843: EV TLS Zertifikat cPSuri fehlt

Ein Ingenieur von Google meldete Paul van Brouwershaven (Director of Technology bei Entrust), dass in über zwanzigtausend Zertifikaten ein erforderliches Feld fehlte. Diese Zertifikate wiederum hätten als ungültig behandelt und als "falsch ausgestellt" gekennzeichnet werden müssen. - Entrust erklärte, dass es sich um einen Fehler handelte, der auf eine Fehlinterpretation der kürzlich geänderten Anforderungen zurückzuführen war.

Das eigentliche Drama begann, als ein Nutzer kommentierte, Entrust sei immer noch Zertifikate falsch ausstellt[Kommentar #3]. Hatte Entrust seinen Fehler behoben? Im Moment war das noch ungewiss.

Entrust erklärte daraufhin, dass man nicht vorhabe, die laufende Ausstellung zu stoppen oder die bereits vorhandenen Zertifikate zu widerrufen, da man das Ganze als unproblematisch ansehe und der Widerruf mehr negative Folgen haben könnte als die Alternative. Dies hatte zur Folge, dass sie ihre eigenen Schlussfolgerungen und Interpretationen zogen.[Kommentar 10]

"Wir sind der festen Überzeugung, dass der Verzicht auf den Widerruf und die Fortsetzung der Ausstellung die Sicherheit, Zuverlässigkeit und Kompatibilität des Ökosystems oder die Nutzer nicht in irgendeiner anderen Weise beeinträchtigt."

Es gingen noch einige weitere Kommentare ein, um Entrust daran zu erinnern, dass sie nicht einfach die bestehenden Richtlinien auslegen und missachten können[Kommentar #5, Kommentar #6, Kommentar #7Mit dem Hinweis auf das Mozilla-CA-Wiki, in dem es heißt: "In Fällen von Fehlausstellungen sollte eine CA fast immer sofort die Ausstellung vonZertifikatenaus dem betroffenen Teil ihrer PKI einstellen", hat Entrust eine Aktion gestartet, um die Ausstellung neuer Zertifikate zu stoppen und bereits ausgestellte Zertifikate zu widerrufen.

Entrust antwortet erneut und wiederholt seine Weigerung, diese falsch ausgestellten Zertifikate zu widerrufen [Kommentar #10], diesmal mit der Begründung, dass dies Tausende von Kunden betreffen würde, von denen viele nicht durch irgendeine Art von automatisiertem Prozess verwaltet werden, und dass die Neuausstellung dieser Zertifikate eine unüberschaubare Menge an Arbeit bedeuten würde. In einem letzten Akt des Trotzes äußerte sich der Vertreter von Entrust wie folgt:

"Wenn Mozilla und die Gemeinschaft erwarten, dass Zertifizierungsstellen (CAs) ihre wertvolle Zeit ausschließlich für prinzipielle Fragen verwenden, bewegen wir uns möglicherweise in die falsche Richtung und behindern ungewollt den Fortschritt des Ökosystems."

Gegenwind aus der Gemeinschaft.

Ein Software-Ingenieur antwortete recht knapp und erläuterte die Natur selbstregulierender Ökosysteme, wie z. B. eine Zertifizierungsstelle, die sich nicht an diese selbstregulierenden Regeln hält; anstelle der Selbstregulierung ist die einzige Option (offensichtlich) eine staatliche Lösung, die den Fortschritt noch mehr behindern würde.[Kommentar #11]. Ein anderer Nutzer meldete sich kurz darauf zu Wort, um Entrust daran zu erinnern, dass das "P" in PKI "Public" bedeutet, und dass Entrust das "P" in "Public" bedient, und nicht umgekehrt.[Kommentar #13]

Und wie der Phönix aus der Asche schrieb ein Vertreter des Google Chrome Root Program (der ursprüngliche Berichterstatter in dieser Angelegenheit) einen ausführlichen Kommentar mit einigen sehr spezifischen Fragen.

Sie waren unzufrieden mit der Antwort von Entrust; ein Problem war das Format der Antwort selbst - es fehlten einige wichtige Details, die in den gemeinsamen CA-Leitlinien vorgeschrieben sind, wie z. B. die Angabe der Anzahl der betroffenen Vermögenswerte, eine wichtige Tatsache, die erst in den Antworten und nicht im ursprünglichen Bericht entdeckt wurde. Sie rügten auch, dass Entrust ein fragwürdiges Urteilsvermögen an den Tag gelegt und die Bedenken der Gemeinschaft in einem Fall missachtet habe, der sowohl unnötig als auch vermeidbar war. [Kommentar #19].

Am 18. März 2024 war es neun Stunden lang still im Kommentarbereich dieser Ausgabe, bis eine kurze, pointierte Antwort von Entrust die Stille unterbrach:

"Wir haben die Ausstellung von falsch ausgestellten Zertifikaten eingestellt und das EV-Zertifikatsprofil korrigiert.

Alle betroffenen Kunden werden darüber informiert, dass ihre Zertifikate widerrufen werden.

Wir werden einen Fehler für den verzögerten Widerruf erstellen und in den nächsten Tagen weitere Fragen klären". - Entrust / [Kommentar #20]

Und so gab Entrust am 18. März um 15.00 Uhr PST dem Drängen des Unternehmens nach. Aber sie wussten nicht, dass dies nur der Anfang einer Welle von Anfragen war.

"Sie haben es also in weniger als 10 Stunden geschafft, die Fehlausgabe zu stoppen, aber nur, wenn Google eingreift? Davor wolltet ihr einfach nicht aufhören?", fragte JR Moir in Kommentar #21 - eine berechtigte Frage, die sich zu diesem Zeitpunkt wahrscheinlich viele gestellt haben. JR fährt fort: "Das Vertrauen in Entrust sollte entzogen werden." Der erste Schuss der Revolte ertönte auf der grünen Wiese der Internetsicherheit.

In den nächsten Wochen versuchte Entrust, mit der Community in Kontakt zu treten, um alle betroffenen Zertifikate zu erfassen. Erst am 4. April antwortete Entrust direkt auf die ersten Kommentare und Fragen des Chrome Root Programs in Kommentar Nr. 35. Entrust erklärte, dass ihre Antwort zwar nicht den gängigen Erwartungen an eine Zertifizierungsstelle entspreche, man aber im besten Interesse der Kunden oder, wie sie es ausdrückten, des Web-Ökosystems handeln wolle. Entrust beantwortete dann jede Frage in dem Kommentar, betonte, dass es sich nur um ein Versehen gehandelt habe, und räumte sein Fehlverhalten ein.

"Im Nachhinein räumen wir ein, dass wir die Ausstellung von EV-Zertifikaten ohne den Policy Qualifier nach der Bestätigung des Problems hätten stoppen und dann weiterverfolgen sollen, was wir als mögliches Versehen in den EV-Richtlinien ansahen." - Kommentar #35 / Antwort auf Frage 1 in Kommentar #19

Kommentar Nr. 35 enthält eine Fülle wertvoller Informationen, die einen Einblick in alle Fehltritte geben, die Entrust auf diesem Weg begangen hat, einschließlich Details über den gesamten Ausstellungsprozess; es wurde viel Mühe in die Erklärung einiger der Annahmen gesteckt, die zu diesen Entscheidungen geführt haben; das erforderliche Feld wurde nicht in neue Zertifikate aufgenommen, weil man fälschlicherweise davon ausging, dass es sich um einen Fehler im Text der CA-Leitlinien selbst handelte:

"...wir glaubten, dass das Fehlen von "certificatePolicies:policyQualifiers:qualifier:cPSuri" in den ausgestellten EV-Zertifikaten auf einen Fehler in den EV-Richtlinien zurückzuführen war." - Kommentar #35 (Entrust)

Sechs Tage später veröffentlichte Entrust einen aktualisierten Bericht zu diesem Vorfall(Kommentar Nr. 41), der einen vollständigen Zeitplan der Ereignisse enthielt. Eine Antwort, die den Zorn der Community nur noch einmal hervorrief. In Kommentar Nr. 44 schreibt ein Nutzer, dass er hofft, dass andere Zertifizierungsstellen diesen ganzen Vorfall als eine "Lektion betrachten, aus der sie lernen können", nachdem er festgestellt hat, dass selbst nach drei Wochen noch nicht einmal die Hälfte der "betroffenen Kunden" behoben und nur die Hälfte der falsch ausgestellten Zertifikate widerrufen worden ist. Und dann ein weiterer Aufruf zur Entfernung von Entrust:

"Diese wiederholten Versäumnisse zeigen deutlich, dass Entrust in der WebPKI nicht vertrauenswürdig ist und entfernt werden muss." - JR Moir(Kommentar #44)

Daraufhin erklärte der Vertreter von Entrust, dass sich sein Kundenstamm von dem anderer (möglicherweise größerer) Zertifizierungsstellen unterscheide, was sich möglicherweise auf die Kundengruppe bezieht, die Entrust anspricht. Entrust fährt fort:

"Wir hoffen, dass die Mitglieder der Gemeinschaft, die über Erfahrungen in dem Bereich verfügen, in dem Entrust tätig ist, unsere Herausforderungen verstehen und dass wir alles tun, was wir können, um unsere Teilnehmer besser auf Sicherheitsvorfälle vorzubereiten und flexibler zu machen" - Entrust(Kommentar #46)

Danach verstummt der Thread, abgesehen von ein paar Kommentaren hier und da mit Geschichten und Erzählungen über Entrusts historische Versäumnisse. Der letzte Kommentar stammt von Ben Wilson, dem Programmmanager von Mozilla CA, der zusätzliche Maßnahmen von Entrust forderte, die unter der Ticket-ID #1901270 veröffentlicht wurden : Entrust: Aktionspunkte aus dem Bericht vom Juni 2024.

Dies war nur das jüngste Drama, in das Entrust verwickelt war. Im März 2024 wurde berichtet, dass Entrust 1.176 Zertifikate falsch ausgestellt hat, weil seine Werkzeuge einige nicht konforme Zertifikate nicht erkannt haben. Während dies an sich keine große Sache war, wurden die von diesem Fehler betroffenen Zertifikate nicht rechtzeitig widerrufen, was dazu führte, dass ein weiterer Vorfall an die Öffentlichkeit gelangte.

Einige Kommentatoren wiesen sogar auf die spärlichen Folgemaßnahmen hin und wiesen darauf hin, dass Entrust anscheinend den Kunden die Schuld dafür gibt, dass sie diese Zertifikate nicht schnell widerrufen können. Einen Monat zuvor wurde berichtet, dass Entrust SHA-1 (ein veralteter Hash-Algorithmus) zum Signieren von Antworten über OCSP verwendet . Daraufhin gab es ein langes Hin und Her mit der gesamten Community, in dem frustrierte Fragen darüber beantwortet wurden, warum man diese Informationen nicht früher entdeckt hatte.

Es gibt noch weitere Beispiele dafür, dass die Öffentlichkeit das Vertrauen in Entrust verloren hat, wobei es in den meisten Fällen um verzögerte Antworten und langsame Sperrfristen für Zertifikate geht. Diese Probleme sind der Grund, warum Google beschlossen hat, von Entrust ausgestellte Zertifikate in seinem Stammzertifikatspeicher nicht mehr zu unterstützen.

Nach mehr als zwei Jahrzehnten in der Branche und ihrer (leider) schlecht aufgenommenen jüngeren Geschichte sieht es so aus, als ob dies der Anfang vom Ende für die Zertifizierungsstelle von Entrust sein könnte. Heute ist es Google, morgen könnten es Mozilla und Microsoft sein.

Das ist eine ziemlich große Sache; eine Entscheidung, die man nicht auf die leichte Schulter nehmen sollte. Wenn überhaupt, dann kann man daraus Lehren ziehen. Die Erosion des Vertrauens zwischen einem öffentlichen Dienst und seiner Gemeinschaft kann schlimme Folgen haben.

Signierte Zertifikat-Zeitstempel

SCTs sind digitale Quittungen, die von Certificate Transparency (CT)-Protokollen ausgestellt werden, wenn eine CA ein Zertifikat zur Protokollierung vorlegt. Diese Zeitstempel sind der Beweis dafür, dass das Zertifikat in einem öffentlichen Protokoll aufgezeichnet wurde, was eine öffentliche Prüfung ermöglicht. Wenn eine Zertifizierungsstelle (CA) ein neues Zertifikat ausstellt, sendet sie es an ein oder mehrere CT-Logs. Sobald das CT-Protokoll das Zertifikat erhält und eine Aufzeichnung davon erstellt, generiert das CT-Protokoll ein SCT, das Folgendes enthält:

• Ein Zeitstempel, der angibt, wann das Zertifikat protokolliert wurde
• Der Hash-Wert des Zertifikats
• Ein eindeutiger Bezeichner für das Protokoll
• Eine digitale Signatur, die mit dem privaten Schlüssel des Protokolls erstellt wird.

Dieser SCT wird dann meist direkt in das Zertifikat eingebettet. Das folgende Beispiel zeigt, wie man die SCT-Informationen des Domänennamens "www.censys.com" anzeigen könnte:

Die Ausgabe dieses Befehls sieht ähnlich aus wie die folgende:

• Version: Gibt die Version des SCT an; hier ist es Version 1.
• Zeitstempel: Das Datum und die Uhrzeit, zu der der SGT ausgestellt wurde.
• Unterschrift: Die kryptografische Signatur, die den SCT validiert.
• Protokoll-ID: Ein eindeutiger Bezeichner für das Protokoll, das den SGT ausgestellt hat, dargestellt als eine Folge von Hexadezimalbytes

Um den Log-Provider für eine bestimmte "Log-ID" zu finden (wo Details über diese Ausgabe zu finden sind), können die folgenden Befehle verwendet werden:

$ LOGID=$(echo 3F:17:4B:4F:D7:22:47:58:94:1D:65:1C:84:BE:0D:12:ED:90:37:7F:1F:85:6A:EB:C1:BF:28:85:EC:F8:64:6E | \
  sed -s 's/://g' | \
  xxd -p -r | base64); \
 curl -s https://www.gstatic.com/ct/log_list/v3/all_logs_list.json | \
 jq ".operators[].logs[]|select(.log_id == \"$LOGID\")|."

{
  "description": "Let's Encrypt 'Oak2024H2' log",
  "log_id": "PxdLT9ciR1iUHWUchL4NEu2QN38fhWrrwb8ohez4ZG4=",
  "key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE13PWU0fp88nVfBbC1o9wZfryUTapE4Av7fmU01qL6E8zz8PTidRfWmaJuiAfccvKu5+f81wtHqOBWa+Ss20waA==",
  "url": "https://oak.ct.letsencrypt.org/2024h2/",
  "mmd": 86400,
  "state": {
    "usable": {
      "timestamp": "2022-11-30T17:00:00Z"
    }
  },
  "temporal_interval": {
    "start_inclusive": "2024-06-20T00:00:00Z",
    "end_exclusive": "2025-01-20T00:00:00Z"
  }
}

Die obige Ausgabe zeigt uns, dass wir diesen SCT mit Hilfe des "Let's Encrypt 'Oak2024H2' log"-Servers validieren können.

Im Falle von Google Chrome wird dem Überprüfungsprozess für jedes beliebige Zertifikat ein zusätzlicher Schritt (oder eine Einschränkung) hinzugefügt. Diese Einschränkung prüft, ob der SGT am oder nach dem 31. Oktober 2024 erstellt wurde, und wenn die Einschränkung erfüllt ist, wird das Zertifikat abgelehnt.

Die Auswirkungen auf das Internet

Wir können die Censys Host- und Zertifikatsdatensätze untersuchen, um die Stellung von Entrust unter den anderen Zertifizierungsstellen und die potenziellen Auswirkungen zu verstehen, die dieses Problem haben kann, wenn es nicht umgehend behoben wird.

Aufschlüsselung der Zertifizierungsstellen

Insgesamt vertraut Google den Zertifikaten von 464 verschiedenen Stellen, die insgesamt 7.559.114.541 (sieben Milliarden) ausgestellte Zertifikate besitzen. Darunter rangiert Entrust, Inc. mit 3.999.827 (0,05 %) Google-vertrauten Zertifikaten auf Platz 22 und AffirmTrust mit satten 37.646 auf Platz 78.