Notiz Übersetzer: Zur besseren Lesbarkeit werden die Daten in Moskauer Zeit angegeben
Wir haben kürzlich den Ablauf eines der zum Signieren von Add-ons verwendeten Zertifikate übersehen. Dies führte dazu, dass Add-ons für Benutzer deaktiviert wurden. Nachdem das Problem nun größtenteils behoben ist, möchte ich Ihnen gerne Einzelheiten darüber mitteilen, was passiert ist und welche Arbeit geleistet wurde.
Hintergrund: Ergänzungen und Signaturen
Installierte Add-Ons müssen vorhanden sein Digitale Unterschrift, das Benutzer vor bösartigen Add-ons schützt und eine minimale Überprüfung der Add-ons durch Mozilla-Mitarbeiter erfordert. Wir haben diese Anforderung im Jahr 2015 eingeführt, weil wir Probleme hatten ernsthafte Probleme mit bösartigen Add-ons.
So funktioniert es: Jede Kopie von Firefox enthält ein „Root-Zertifikat“. Der Schlüssel zu dieser „Wurzel“ ist in gespeichert Hardware-Sicherheitsmodul (HSM)ohne Netzwerkzugriff. Alle paar Jahre wird mit diesem Schlüssel ein neues „Zwischenzertifikat“ signiert, das beim Signieren von Add-Ons verwendet wird. Wenn ein Entwickler ein Add-on einreicht, erstellen wir ein temporäres „Endzertifikat“ und signieren es mit einem Zwischenzertifikat. Das Add-on selbst wird dann mit dem endgültigen Zertifikat signiert. Schematisch es sieht aus wie das.
Bitte beachten Sie, dass jedes Zertifikat einen „Betreff“ (für den das Zertifikat ausgestellt wurde) und einen „Aussteller“ (der das Zertifikat ausgestellt hat) hat. Im Falle eines Stammzertifikats ist „Betreff“ = „Aussteller“, bei anderen Zertifikaten ist der Aussteller des Zertifikats jedoch der Betreff des übergeordneten Zertifikats, mit dem es signiert wird.
Ein wichtiger Punkt: Jedes Add-on wird durch ein eindeutiges Endzertifikat signiert, aber fast immer werden diese Endzertifikate durch dasselbe Zwischenzertifikat signiert.
Anmerkung des Autors: Die Ausnahme bilden sehr alte Ergänzungen. Damals wurden verschiedene Zwischenzertifikate verwendet.
Dieses Zwischenzertifikat verursachte Probleme: Jedes Zertifikat ist für einen bestimmten Zeitraum gültig. Vor oder nach diesem Zeitraum ist das Zertifikat ungültig und der Browser verwendet keine von diesem Zertifikat signierten Add-ons. Leider ist das Zwischenzertifikat am 4. Mai um 4 Uhr morgens abgelaufen.
Die Konsequenzen zeigten sich nicht sofort. Firefox überprüft die Signaturen installierter Add-ons nicht ständig, sondern etwa alle 24 Stunden, wobei die Überprüfungszeit für jeden Benutzer individuell ist. Dies führte dazu, dass einige Menschen sofort Probleme hatten, während andere erst viel später Probleme hatten. Wir wurden zum ersten Mal auf das Problem aufmerksam, als das Zertifikat ablief, und begannen sofort mit der Suche nach einer Lösung.
Schaden reduzieren
Als uns klar wurde, was passiert war, versuchten wir zu verhindern, dass sich die Situation verschlimmerte.
Erstens haben sie aufgehört, Neuzugänge anzunehmen und zu unterzeichnen. Es macht keinen Sinn, hierfür ein abgelaufenes Zertifikat zu verwenden. Rückblickend würde ich sagen, wir hätten alles so lassen können, wie es war. Wir nehmen nun wieder Nahrungsergänzungsmittel an.
Zweitens wurde sofort ein Fix verschickt, der die tägliche Überprüfung der Signaturen verhinderte. Daher haben wir diejenigen Benutzer gerettet, deren Browser in den letzten XNUMX Stunden noch keine Zeit hatte, die Add-ons zu überprüfen. Dieser Fix wurde inzwischen zurückgezogen und wird nicht mehr benötigt.
Parallelbetrieb
Theoretisch sieht die Lösung des Problems einfach aus: Erstellen Sie ein neues gültiges Zwischenzertifikat und signieren Sie jedes Add-on neu. Das wird leider nicht funktionieren:
- Wir können nicht schnell 15 Add-ons auf einmal neu signieren, das System ist für eine solche Belastung nicht ausgelegt
- Nachdem wir die Ergänzungen unterzeichnet haben, müssen die aktualisierten Versionen an die Benutzer geliefert werden. Die meisten Add-ons werden von Mozilla-Servern installiert, sodass Firefox innerhalb der nächsten XNUMX Stunden Updates finden wird. Einige Entwickler vertreiben jedoch signierte Add-ons über Kanäle von Drittanbietern, sodass Benutzer solche Add-ons manuell aktualisieren müssten
Stattdessen haben wir versucht, eine Lösung zu entwickeln, die alle Benutzer erreicht, ohne dass sie viel oder gar keine Maßnahmen ergreifen müssen.
Ziemlich schnell kamen wir zu zwei Hauptstrategien, die wir parallel verwendeten:
- Aktualisieren Sie Firefox, um die Gültigkeitsdauer des Zertifikats zu ändern. Dadurch funktionieren vorhandene Add-ons wie von Zauberhand wieder, es ist jedoch die Veröffentlichung und Auslieferung einer neuen Version von Firefox erforderlich
- Generieren Sie ein gültiges Zertifikat und überzeugen Sie Firefox irgendwie davon, es anstelle des vorhandenen, abgelaufenen Zertifikats zu akzeptieren
Wir entschieden uns zunächst für die erste Option, die durchaus praktikabel schien. Am Ende des Tages haben sie einen zweiten Fix (ein neues Zertifikat) veröffentlicht, über den wir später sprechen werden.
Ersetzen eines Zertifikats
Wie ich oben erwähnt habe, war Folgendes erforderlich:
- Erstellen Sie ein neues gültiges Zertifikat
- Installieren Sie es remote in Firefox
Um zu verstehen, warum das funktioniert, werfen wir einen genaueren Blick auf den Add-on-Verifizierungsprozess. Das Add-on selbst besteht aus einer Reihe von Dateien, einschließlich einer Kette von Zertifikaten, die zum Signieren verwendet werden. Dadurch kann das Add-on überprüft werden, wenn der Browser das Root-Zertifikat kennt, das zur Build-Zeit in Firefox integriert wird. Wie wir jedoch bereits wissen, ist das Zwischenzertifikat abgelaufen, sodass eine Überprüfung des Add-ons nicht möglich ist.
Wenn Firefox versucht, ein Add-on zu überprüfen, ist er nicht auf die Verwendung der im Add-on selbst enthaltenen Zertifikate beschränkt. Stattdessen versucht der Browser, eine gültige Zertifikatskette zu erstellen, beginnend mit dem Endzertifikat bis zum Stammzertifikat. Auf der ersten Ebene beginnen wir mit dem Endzertifikat und suchen dann das Zertifikat, dessen Betreff der Aussteller des Endzertifikats (d. h. des Zwischenzertifikats) ist. Normalerweise wird dieses Zwischenzertifikat mit dem Add-on geliefert, aber auch jedes Zertifikat aus dem Speicher des Browsers kann als Zwischenzertifikat dienen. Wenn wir aus der Ferne ein neues gültiges Zertifikat zum Zertifikatspeicher hinzufügen können, wird Firefox versuchen, es zu verwenden. Die Situation vor und nach der Installation eines neuen Zertifikats.
Nach der Installation des neuen Zertifikats hat Firefox bei der Validierung der Zertifikatskette zwei Möglichkeiten: Verwenden Sie das alte ungültige Zertifikat (was nicht funktioniert) oder das neue gültige Zertifikat (was funktioniert). Es ist wichtig, dass das neue Zertifikat denselben Antragstellernamen und denselben öffentlichen Schlüssel wie das alte Zertifikat enthält, damit seine Signatur auf dem endgültigen Zertifikat gültig ist. Firefox ist schlau genug, beide Optionen auszuprobieren, bis er eine findet, die funktioniert, sodass die Add-ons erneut getestet werden. Beachten Sie, dass dies dieselbe Logik ist, die wir zur Validierung von TLS-Zertifikaten verwenden.
Anmerkung des Autors: Leser, die mit WebPKI vertraut sind, werden feststellen, dass Gegenzertifikate auf genau die gleiche Weise funktionieren.
Das Tolle an diesem Fix ist, dass Sie bestehende Add-ons nicht erneut signieren müssen. Sobald der Browser das neue Zertifikat erhält, funktionieren alle Add-Ons wieder. Die verbleibende Herausforderung besteht darin, den Benutzern das neue Zertifikat (automatisch und aus der Ferne) bereitzustellen und Firefox dazu zu bringen, deaktivierte Add-Ons erneut zu überprüfen.
Normandie und das Forschungssystem
Ironischerweise wird dieses Problem durch ein spezielles Add-on namens „System“ gelöst. Um Forschung durchzuführen, haben wir ein System namens Normandy entwickelt, das den Benutzern Forschungsergebnisse liefert. Diese Studien werden automatisch im Browser durchgeführt und bieten einen erweiterten Zugriff auf die internen APIs von Firefox. Research kann dem Zertifikatspeicher neue Zertifikate hinzufügen.
Anmerkung des Autors: Wir fügen kein Zertifikat mit besonderen Privilegien hinzu; Es ist vom Stammzertifikat signiert, daher vertraut Firefox ihm. Wir fügen es einfach dem Pool der Zertifikate hinzu, die vom Browser verwendet werden können.
Die Lösung besteht also darin, eine Studie zu erstellen:
- Installieren des neuen Zertifikats, das wir für Benutzer erstellt haben
- Dadurch wird der Browser gezwungen, deaktivierte Add-ons erneut zu überprüfen, damit sie wieder funktionieren
„Aber Moment“, sagen Sie, „Add-ons funktionieren nicht, wie kann ich ein System-Add-on starten?“ Unterschreiben wir es mit einem neuen Zertifikat!
Alles in allem... warum dauert es so lange?
Also der Plan: ein neues Zertifikat ausstellen, um das alte zu ersetzen, ein System-Add-on erstellen und es über Normandy für Benutzer installieren. Die Probleme begannen, wie gesagt, am 4. Mai um 4:00 Uhr und bereits um 12:44 Uhr desselben Tages, weniger als 9 Stunden später, schickten wir eine Lösung in die Normandie. Es dauerte weitere 6-12 Stunden, bis alle Benutzer erreicht waren. Gar nicht schlecht, aber auf Twitter fragen sich die Leute, warum wir nicht schneller hätten handeln können.
Zunächst dauerte es einige Zeit, ein neues Zwischenzeugnis auszustellen. Wie oben erwähnt, wird der Schlüssel zum Stammzertifikat offline im Hardware-Sicherheitsmodul gespeichert. Aus Sicherheitsgründen ist das gut, da der Root nur sehr selten verwendet wird und zuverlässig geschützt werden sollte, aber etwas umständlich, wenn Sie dringend ein neues Zertifikat signieren müssen. Einer unserer Ingenieure musste zum HSM-Lager reisen. Dann gab es erfolglose Versuche, das richtige Zertifikat auszustellen, und jeder Versuch kostete ein bis zwei Teststunden.
Zweitens hat die Entwicklung des System-Add-Ons einige Zeit in Anspruch genommen. Vom Konzept her ist es sehr einfach, aber auch einfache Programme erfordern Pflege. Wir wollten sicherstellen, dass wir die Situation nicht noch schlimmer machen. Forschungsergebnisse müssen getestet werden, bevor sie an Benutzer gesendet werden. Darüber hinaus muss das Add-on signiert werden, aber unser Add-on-Signatursystem war deaktiviert, sodass wir einen Workaround finden mussten.
Als wir schließlich die Forschungsergebnisse zur Einreichung bereit hatten, dauerte die Bereitstellung einige Zeit. Der Browser sucht alle 6 Stunden nach Normandy-Updates. Da nicht alle Computer immer eingeschaltet und mit dem Internet verbunden sind, wird es einige Zeit dauern, bis sich das Problem bei den Benutzern ausbreitet.
Letzte Schritte
Die Recherche sollte das Problem für die meisten Benutzer beheben, steht aber nicht jedem zur Verfügung. Einige Benutzer benötigen eine besondere Vorgehensweise:
- Benutzer, die Forschung oder Telemetrie deaktiviert haben
- Benutzer der Android-Version (Fennec), bei der die Recherche überhaupt nicht unterstützt wird
- Benutzer benutzerdefinierter Builds von Firefox ESR in Unternehmen, in denen Telemetrie nicht aktiviert werden kann
- Benutzer, die hinter MitM-Proxys sitzen, da unser Add-on-Installationssystem Key Pinning verwendet, was mit solchen Proxys nicht funktioniert
- Benutzer älterer Firefox-Versionen, die keine Recherche unterstützen
Gegen die letztgenannte Benutzerkategorie können wir nichts unternehmen – sie sollten trotzdem auf die neue Version von Firefox aktualisieren, da veraltete Versionen schwerwiegende, nicht behobene Schwachstellen aufweisen. Wir wissen, dass einige Leute bei älteren Versionen von Firefox bleiben, weil sie alte Add-ons ausführen möchten, aber viele der alten Add-ons wurden bereits auf neuere Versionen des Browsers portiert. Für andere Benutzer haben wir einen Patch entwickelt, der ein neues Zertifikat installiert. Es wurde als Bugfix-Release veröffentlicht (Anmerkung des Übersetzers: Firefox 66.0.5), sodass die Leute es – höchstwahrscheinlich bereits – über den regulären Update-Kanal erhalten. Wenn Sie eine benutzerdefinierte Version von Firefox ESR verwenden, wenden Sie sich bitte an Ihren Betreuer.
Wir verstehen, dass dies nicht ideal ist. In einigen Fällen haben Benutzer Add-on-Daten verloren (z. B. Add-on-Daten). Container mit mehreren Konten).
Dieser Nebeneffekt ließ sich nicht vermeiden, aber wir glauben, dass wir kurzfristig die beste Lösung für die meisten Benutzer gewählt haben. Langfristig werden wir nach anderen, fortschrittlicheren Architekturansätzen suchen.
Unterricht
Erstens hat unser Team hervorragende Arbeit geleistet und in weniger als 12 Stunden nach Entdeckung des Problems eine Lösung erstellt und versendet. Als jemand, der an den Treffen teilgenommen hat, kann ich sagen, dass die Menschen in dieser schwierigen Situation sehr hart gearbeitet haben und nur sehr wenig Zeit verschwendet wurde.
Offensichtlich hätte das alles überhaupt nicht passieren dürfen. Es lohnt sich eindeutig, unsere Prozesse anzupassen, um die Wahrscheinlichkeit solcher Vorfälle zu verringern und die Behebung zu erleichtern.
Nächste Woche werden wir eine offizielle Obduktion und eine Liste der Änderungen veröffentlichen, die wir vornehmen möchten. Im Moment werde ich meine Gedanken teilen. Erstens muss es eine bessere Möglichkeit geben, den Status einer potenziellen Zeitbombe zu überwachen. Wir müssen sicher sein, dass wir uns nicht in einer Situation befinden, in der einer von ihnen plötzlich funktioniert. Wir arbeiten noch an den Details, aber es ist zumindest notwendig, all diese Dinge zu berücksichtigen.
Zweitens brauchen wir einen Mechanismus, um Benutzern schnell Aktualisierungen bereitzustellen, selbst wenn – insbesondere wenn – alles andere fehlschlägt. Es war toll, dass wir das „Recherche“-System nutzen konnten, aber es ist ein unvollkommenes Werkzeug und hat einige unerwünschte Nebenwirkungen. Insbesondere wissen wir, dass viele Benutzer automatische Updates aktiviert haben, aber lieber nicht an der Forschung teilnehmen würden (ich gebe zu, ich habe sie auch deaktiviert!). Gleichzeitig brauchen wir eine Möglichkeit, Updates an Benutzer zu senden, aber unabhängig von der internen technischen Implementierung sollten Benutzer Updates (einschließlich Hotfixes) abonnieren können, sich aber von allem anderen abmelden können. Darüber hinaus sollte der Update-Kanal schneller reagieren als derzeit. Selbst am 6. Mai gab es noch Benutzer, die weder den Fix noch die neue Version nutzten. An diesem Problem wurde bereits gearbeitet, aber was passiert ist, hat gezeigt, wie wichtig es ist.
Abschließend werfen wir einen genaueren Blick auf die Sicherheitsarchitektur des Add-ons, um sicherzustellen, dass es das richtige Maß an Sicherheit bei minimalem Risiko bietet, dass etwas kaputt geht.
Nächste Woche werden wir uns die Ergebnisse einer genaueren Analyse des Geschehens ansehen, aber in der Zwischenzeit beantworte ich gerne Fragen per E-Mail: [E-Mail geschützt]
Source: linux.org.ru