Die Korrektur lief über Gos URGENT-Track, der den schwerwiegendsten Fällen vorbehalten ist; das Projekt empfiehlt ein sofortiges Update. Gos Sicherheitsrichtlinie definiert URGENT-Fälle als „eine Bedrohung für die Integrität des Go-Ökosystems“ oder als aktiv ausgenutzte Fehler mit schwerem Schaden und hält fest, dass es dafür keine jüngeren Beispiele gebe. Welcher der beiden Fälle vorliegt, hat Go nicht gesagt. Auch die sonst übliche Vorankündigung, wie sie vor den Sicherheitsreleases vom 8. Oktober verschickt wurde, blieb diesmal aus.

Zwei Tage zuvor, am 17. Oktober, hatte Mozilla sechs Zwischenzertifikate, die unter eMudhras emSign Root TLS CA - G3 ausgestellt wurden, in OneCRL aufgenommen – jene Liste, mit der Firefox Zertifikate blockiert. Der zugehörige Mozilla-Bug ist nicht öffentlich einsehbar; weder Mozilla noch Go haben den Anlass genannt. Ob Chrome, Apple oder Microsoft vergleichbare Schritte unternommen haben, ist nicht belegt.

Gos Änderung führt nur die SHA-256-Hashes der acht Schlüssel auf. Ein Kommentator im Go-Issue ordnete alle acht über Zertifikatsdatenbanken eMudhra-Zwischenzertifikaten zu. Demnach handelt es sich um sechs TLS-Intermediates unter derselben emSign Root TLS CA - G3, die auch Mozillas Einträge nennen, sowie um zwei Code-Signing-Intermediates unter emSign Root CS CA - G3:

  • TLS, domainvalidiert: EM DV TLS CA - G3B (eMudhra BV, Niederlande) und EM DV TLS CA - G3C (eMudhra Inc, USA)
  • TLS, organisationsvalidiert: EM OV TLS CA - G3B und EM OV TLS CA - G3C
  • TLS, Extended Validation: EM EV TLS CA - G3B und EM EV TLS CA - G3C
  • Code Signing: EM OV CS CA - G3B und EM OV CS CA - G3C

Eine unabhängige Prüfung der Hashes gegen die Zertifikate liegt nicht vor. Mozillas sechs Einträge tragen dieselbe ausstellende Wurzel, benennen die sechs Zertifikate in den Aufzeichnungen aber nicht.

Der Filter greift bei jeder Kettenprüfung durch ein Go-Programm. Gebildet wird der Hash des öffentlichen Schlüssels eines Zertifikats, nicht des Zertifikats selbst – damit wird auch eine quersignierte Kopie eines der acht Schlüssel erfasst, also derselbe Schlüssel unter einer anderen Wurzel. Angewendet wird die Sperre in Gos eigenem Prüfer ebenso wie in den macOS- und Windows-Pfaden, die die Prüfung an das Betriebssystem übergeben. Eine abgelehnte Kette liefert den Fehler „x509: no valid chains built“.

Eine Option zum Abschalten enthält die Änderung nicht. Aufgrund des Codeaufbaus greift sie auch dann, wenn ein Programm eigene vertrauenswürdige Wurzeln mitbringt – eine private Installation, die einen der acht Schlüssel bewusst als vertrauenswürdig einstuft, scheitert also ebenfalls. Ob das so beabsichtigt ist, hat das Go-Team nicht mitgeteilt.

Gos Prüfer „führt keinerlei Sperrprüfung durch“, wie die Dokumentation warnt. Er liest auch die Sperrlisten der Browser nicht aus, etwa die CRLSets, die Chrome in diesem Monat gegen nicht autorisierte Google-Zertifikate eingesetzt hat. Einen Schlüssel zu sperren bedeutet für Go daher, ihn in einem Release auszuliefern; Programme verhalten sich bis zu ihrem Neubau wie zuvor. Projekte wie Blueskys indigo wurden am 20. Oktober auf den neuen Releases neu gebaut.

Was bei der Zertifizierungsstelle vorgefallen ist, ist nicht öffentlich. Gos Ankündigung besteht aus einem Satz zu Sicherheitsbedenken. Im Issue bat ein Nutzer darum, der eingecheckte Patch möge erklären, „wer und was ihnen entspricht“; eine Antwort des Go-Teams lag am 20. Oktober nicht vor.

eMudhra ist eine indische Zertifizierungsstelle, die Zertifikate unter der Marke emSign verkauft. Ihre Wurzeln emSign Root CA - G1 und emSign ECC Root CA - G3 sind in den Root-Stores von Chrome, Apple und Mozilla enthalten. Gegenüber Mozilla hatte das Unternehmen Anfang des Jahres erklärt, seine neuere TLS-Wurzel sei durch emSign Root CA - G1 quersigniert – auf diesem Weg führen Zertifikate unter der neueren Wurzel zu einer vertrauenswürdigen Wurzel. Im September endete eine sechswöchige öffentliche Diskussion über eMudhras Antrag, zehn neue Wurzeln in die Root-Programme der Browser- und Betriebssystemhersteller aufzunehmen, darunter emSign Root TLS CA - G3, ohne Einwände.

Zertifikate für eMudhras eigene Domains, darunter emsign.com und emudhra.com, führen über andere eMudhra-Zwischenzertifikate, wie Einträge in Certificate-Transparency-Protokollen am 20. Oktober zeigten. Das Repository des Unternehmens enthielt an diesem Tag keinen Hinweis auf die Zwischenzertifikate; eine öffentliche Stellungnahme von eMudhra lag nicht vor.

Go 1.25 und ältere Versionen werden nicht mehr unterstützt und erhalten keine Korrekturen; bleibt nur der Wechsel auf ein unterstütztes Release von der Downloadseite. Einen temporären Behelf gibt es nicht, und der Filter lässt sich nicht deaktivieren. Betreiber von Diensten, deren Zertifikate über die acht Schlüssel führen, benötigen Zertifikate eines anderen Zwischenzertifikats, bevor neu gebaute Go-Clients sie wieder erreichen.