Go certificate update blockiert acht intermediate CA keys
Das Go certificate update in Go 1.27.3 und Go 1.26.10 bewirkt, dass Software Verbindungen ablehnt, wenn eine certificate chain über einen von acht blockierten keys einer intermediate certificate authority führt. Eine certificate authority (CA) ist eine vertrauenswürdige Organisation, die digitale Zertifikate ausstellt, mit deren Hilfe Software die Identität einer Website oder eines Dienstes bestätigen kann. Beide Go-Versionen erschienen am 20. Oktober, und das Go-Team empfiehlt ein sofortiges Update.
Die Änderung betrifft Programme, die mit den neuen Versionen erstellt wurden. Wenn eines dieser Programme eine Verbindung zu einer Website oder einem Onlinedienst herstellt, prüft der certificate verifier von Go die certificate chain, die das Ziel mit einer vertrauenswürdigen Stelle verbindet. Enthält der Pfad einen der blockierten keys, schlägt die Prüfung fehl und das Programm gibt den Fehler „x509: no valid chains built“ zurück. Websites, die Zertifikate verwenden, welche unterhalb dieser keys ausgestellt wurden, sind daher für neu erstellte Go-Clients nicht mehr erreichbar, bis sie Zertifikate von einer anderen intermediate authority erhalten.
Go hat die CA hinter den keys nicht genannt. In der Ankündigung ist lediglich von konkreten Sicherheitsbedenken hinsichtlich ihres Betriebs die Rede. Das Update wurde über den „URGENT process“ von Go abgewickelt, den die Sicherheitsrichtlinie des Projekts für Bedrohungen der Integrität des Go-Ökosystems oder für aktiv ausgenutzte Schwachstellen mit schwerwiegenden Folgen vorsieht. Das Projekt erklärt, dass es in letzter Zeit keine anderen Probleme mit dieser Einstufung gegeben habe, hat jedoch weder offengelegt, welche Bedingung in diesem Fall zutraf, noch, was bei der CA geschehen ist. Die Veröffentlichung erfolgte außerdem ohne die Vorankündigung, die den Sicherheitsveröffentlichungen von Go vom 8. Oktober vorausging.
Das Update identifiziert die blockierten keys ausschließlich anhand ihrer SHA-256 hashes, also digitaler Fingerabdrücke, die aus ihren public keys berechnet werden. Ein Kommentator im Go-Issue ordnete anhand öffentlicher Zertifikatsdaten alle acht hashes eMudhra-intermediates zu. The Hacker News erklärte, diese Zuordnung nicht unabhängig bestätigt zu haben. Den Erkenntnissen des Kommentators zufolge handelt es sich bei sechs davon um Transport Layer Security (TLS)-intermediates unter emSign Root TLS CA - G3, die zur Absicherung von Verbindungen zu Websites und Diensten verwendet werden. Dabei handelt es sich um EM DV TLS CA - G3B und EM DV TLS CA - G3C für domain-validated Zertifikate, EM OV TLS CA - G3B und EM OV TLS CA - G3C für organisation-validated Zertifikate sowie EM EV TLS CA - G3B und EM EV TLS CA - G3C für extended-validation Zertifikate. Die beiden übrigen, EM OV CS CA - G3B und EM OV CS CA - G3C, sind code-signing intermediates unter emSign Root CS CA - G3.
Mozilla hatte am 17. Oktober sechs von eMudhras emSign Root TLS CA - G3 ausgestellte intermediate certificate zu OneCRL hinzugefügt. OneCRL ist eine von Firefox verwendete Blockliste, mit der Zertifikate abgelehnt werden. Der zugehörige Mozilla-Bug ist nicht öffentlich zugänglich, und Mozilla hat nicht angegeben, warum die Zertifikate hinzugefügt wurden. Die Mozilla-Einträge nennen denselben ausstellenden root, führen die sechs Zertifikate selbst jedoch nicht namentlich auf. Es ist nicht bekannt, ob Chrome, Apple oder Microsoft vergleichbare Maßnahmen ergriffen haben.
Der Filter von Go berechnet aus dem public key jedes Zertifikats einen Fingerabdruck und nicht aus dem vollständigen Zertifikat. Dadurch wird auch ein cross-signed Zertifikat mit demselben key erfasst, das über einen anderen root autorisiert wurde. Die Prüfung erfolgt im Go-eigenen certificate verifier sowie in den Pfaden für macOS und Windows, in denen Go die Prüfung an das Betriebssystem delegiert. Sie scheint auch dann zu greifen, wenn eine Anwendung ihre eigenen trusted roots bereitstellt, einschließlich privater Umgebungen, die bewusst einem der keys vertrauen. Go hat nicht mitgeteilt, ob die Blockierung solcher privaten Konfigurationen beabsichtigt war, und das Update bietet keine Möglichkeit, den Filter zu deaktivieren.
Diese Unterscheidung ist wichtig, weil laut der Dokumentation von Go dessen verifier kein revocation checking durchführt, also nicht prüft, ob ein Zertifikat vor seinem Ablaufdatum zurückgezogen wurde. Er nutzt außerdem keine von Browsern gepflegten Blockiersysteme wie die CRLSets, die Chrome in diesem Monat gegen betrügerische Google-Zertifikate einsetzte. Go muss die blockierten keys stattdessen über eine Softwareveröffentlichung verteilen. Bereits vorhandene Anwendungen behalten ihr bisheriges Verhalten bei, bis Entwickler sie mit einer aktualisierten Go-Version neu erstellen. Projekte wie Blueskys indigo wurden am 20. Oktober mit den neuen Versionen neu erstellt.
eMudhra ist eine indische CA, die Zertifikate unter der Marke emSign verkauft. Ihre emSign Root CA - G1 und emSign ECC Root CA - G3 sind in den root stores von Chrome, Apple und Mozilla enthalten. Das Unternehmen hatte Mozilla zuvor mitgeteilt, dass der neuere TLS root von emSign Root CA - G1 cross-signed ist. Dadurch können Zertifikate unterhalb dieses neueren root eine Verbindung zu einem bereits vertrauenswürdigen root herstellen. Eine sechswöchige öffentliche Diskussion über die Aufnahme von zehn neuen eMudhra roots in die root programs von Browsern und Betriebssystemen, darunter emSign Root TLS CA - G3, endete im September ohne Einwände.
Von The Hacker News am 20. Oktober geprüfte certificate transparency records zeigten, dass die Zertifikate für eMudhras eigene Domains, darunter emsign.com und emudhra.com, andere eMudhra-intermediates verwendeten. Das Zertifikats-Repository des Unternehmens enthielt an diesem Tag keinen Hinweis auf die blockierten intermediates, und The Hacker News fand keine öffentliche Stellungnahme von eMudhra. Ein Nutzer forderte außerdem das Go-Team auf, zu erklären, welche Organisationen und Zertifikate der implementierten Sperre entsprachen. Bis zum 20. Oktober hatte das Team jedoch nicht geantwortet.
Administratoren sollten unterstützte Go-Versionszweige aktualisieren und betroffene Anwendungen neu erstellen. Anschließend sollten sie alle daraus resultierenden Fehler der certificate chain untersuchen. Go 1.25 und frühere Versionen werden nicht mehr unterstützt und erhalten diesen Fix nicht. Nutzer dieser Versionszweige müssen daher über die Downloadseite von Go zu einer unterstützten Version wechseln. Es gibt keinen dokumentierten vorübergehenden Workaround, und Websites, deren Zertifikate über die blockierten keys führen, benötigen einen Ersatz, der über ein anderes intermediate ausgestellt wurde. Für Organisationen, die betroffene Anwendungen und Zertifikatspfade überprüfen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen an.