Anmerkung des Übersetzers: Zur Lesefreundlichkeit sind die Daten nach Moskauer Zeit angegeben.
Kürzlich haben wir die Frist für eines der Zertifikate, das zur Signatur von Erweiterungen verwendet wird, verpasst. Dies führte zur Deaktivierung von Erweiterungen für die Benutzer. Jetzt, da das Problem größtenteils behoben ist, möchte ich die Einzelheiten des Vorfalls sowie die durchgeführte Arbeit erläutern.
Hintergrund: Erweiterungen und Signaturen
Installierte Add-ons müssen eine digitale Signatur, die die Benutzer vor bösartigen Erweiterungen schützt, und erfordert eine minimale Überprüfung der Add-ons durch die Mitarbeiter von Mozilla. Dieses Erfordernis haben wir 2015 eingeführt, da wir ernste Probleme mit bösartigen Erweiterungen hatten.
So funktioniert es: Jede Firefox-Version enthält ein „Root-Zertifikat“. Der Schlüssel zu diesem „Root“ wird in einem Hardware-Sicherheitsmodul (HSM), das keinen Netzwerkzugang hat, aufbewahrt. Alle paar Jahre wird mit diesem Schlüssel ein neues „Intermediate-Zertifikat“ signiert, das zur Signatur von Add-ons verwendet wird. Wenn ein Entwickler ein Add-on sendet, erstellen wir ein temporäres „Endzertifikat“ und signieren es mit dem Intermediate-Zertifikat. Dann wird das Add-on mit dem Endzertifikat signiert. Schematisch sieht das folgendermaßen aus:.
Bitte beachten: Jedes Zertifikat hat ein „Subjekt“ (an wen das Zertifikat ausgestellt wurde) und einen „Aussteller“ (wer das Zertifikat ausgestellt hat). Im Fall des Root-Zertifikats ist „Subjekt“ = „Aussteller“, aber bei anderen Zertifikaten ist der Aussteller des Zertifikats das Subjekt des übergeordneten Zertifikats, von dem es signiert wurde.
Ein wichtiger Punkt: Jedes Add-on ist mit einem einzigartigen Endzertifikat signiert, aber fast immer sind diese Endzertifikate mit demselben Intermediate-Zertifikat signiert.
Hinweis des Autors: Eine Ausnahme bilden sehr alte Add-ons. Damals wurden verschiedene Intermediate-Zertifikate verwendet.
Dieses Zwischenzertifikat hat Probleme verursacht: Jedes Zertifikat ist nur für einen bestimmten Zeitraum gültig. Vor oder nach diesem Zeitraum ist das Zertifikat ungültig, und der Browser wird keine mit diesem Zertifikat signierten Add-ons verwenden. Leider ist die Gültigkeit des Zwischenzertifikats am 4. Mai um 4 Uhr abgelaufen.
Die Folgen traten nicht sofort auf. Firefox überprüft die Signaturen installierter Add-ons nicht ständig, sondern etwa einmal alle 24 Stunden, wobei der Zeitpunkt der Überprüfung für jeden Benutzer individuell ist. Infolgedessen hatten einige Personen sofort Probleme, während es bei anderen viel später auftrat. Wir erfuhren zum ersten Mal von dem Problem etwa in dem Moment, als die Gültigkeit des Zertifikats ablief, und begannen sofort mit der Suche nach einer Lösung.
Schaden reduzieren
Sobald wir verstanden haben, was passiert ist, haben wir versucht, eine Verschlechterung der Situation zu vermeiden.
Zunächst stellten wir die Annahme und Signierung neuer Add-ons ein. Es macht keinen Sinn, dafür ein abgelaufenes Zertifikat zu verwenden. Rückblickend würde ich sagen, dass wir alles so belassen hätten, wie es war. Jetzt wurde die Annahme der Add-ons wieder aufgenommen.
Zweitens haben wir sofort einen Fix verschickt, der die tägliche Überprüfung der Signaturen verhinderte. Auf diese Weise haben wir die Benutzer gerettet, deren Browser die Add-ons in den letzten 24 Stunden noch nicht überprüft hatte. Dieser Fix wurde jetzt zurückgezogen, da er nicht mehr benötigt wird.
Parallelarbeit
Theoretisch sieht die Lösung des Problems einfach aus: Wir erstellen ein neues gültiges Zwischenzertifikat und signieren jedes Add-on neu. Leider wird das nicht funktionieren:
- Wir können nicht einfach 15.000 Add-ons auf einmal neu signieren, das System ist nicht für diese Belastung ausgelegt.
- Nachdem wir die Add-ons signiert haben, müssen die aktualisierten Versionen an die Benutzer verteilt werden. Die meisten Add-ons werden von Mozilla-Servern installiert, daher wird Firefox in den nächsten 24 Stunden die Updates finden, aber einige Entwickler verbreiten signierte Add-ons über andere Kanäle, sodass die Benutzer solche Add-ons manuell aktualisieren müssten.
Stattdessen haben wir versucht, einen Fix zu entwickeln, der alle Benutzer erreicht, ohne dass dies (oder fast ohne dass dies) von ihrer Seite erforderlich ist.
Relativ schnell kamen wir zu zwei Hauptstrategien, die wir parallel einsetzten:
- Firefox aktualisieren, um die Gültigkeitsdauer des Zertifikats zu ändern. Dadurch werden vorhandene Erweiterungen auf magische Weise wieder funktionieren, erfordert jedoch die Bereitstellung und Auslieferung einer neuen Firefox-Version.
- Ein gültiges Zertifikat erstellen und Firefox auf irgendeine Weise davon überzeugen, es anstelle des abgelaufenen zu akzeptieren.
Wir entschieden uns zunächst für die erste Option, die durchaus machbar erschien. Am Ende des Tages veröffentlichten wir auch den zweiten Fix (neues Zertifikat), über den wir später sprechen werden.
Zertifikat ersetzen
Wie oben erwähnt, war erforderlich:
- ein neues gültiges Zertifikat zu erstellen
- es remote in Firefox zu installieren
Um zu verstehen, warum dies funktionieren wird, betrachten wir den Überprüfungsprozess der Erweiterung genauer. Die Erweiterung selbst wird als eine Reihe von Dateien geliefert, einschließlich einer Zertifikatskette, die zur Signatur verwendet wird. Daher kann die Erweiterung überprüft werden, wenn der Browser das Wurzelzertifikat kennt, das während der Erstellung in Firefox eingebettet ist. Wie wir jedoch bereits wissen, ist das Zwischenzertifikat abgelaufen, sodass die Überprüfung der Erweiterung unmöglich ist.
Wenn Firefox versucht, die Erweiterung zu überprüfen, beschränkt er sich nicht auf die Verwendung der Zertifikate, die in der Erweiterung selbst enthalten sind. Stattdessen versucht der Browser, eine gültige Zertifikatskette zu erstellen, beginnend mit dem Endzertifikat und fährt fort, bis er die Wurzel erreicht. Auf der ersten Ebene beginnen wir mit dem Endzertifikat und suchen dann das Zertifikat, dessen Subjekt der Herausgeber des Endzertifikats ist (also das Zwischenzertifikat). In der Regel wird dieses Zwischenzertifikat mit der Erweiterung geliefert, aber auch jedes Zertifikat aus dem Browser-Speicher kann dafür verwendet werden. Wenn wir das neue gültige Zertifikat remote im Zertifikatsspeicher hinzufügen können, wird Firefox versuchen, es zu verwenden. Die Situation vor und nach der Installation des neuen Zertifikats..
Nach der Installation des neuen Zertifikats wird Firefox zwei Optionen bei der Überprüfung der Zertifikatkette haben: entweder das alte ungültige Zertifikat (das nicht funktionieren wird) oder das neue gültige (das funktionieren wird). Wichtig ist, dass das neue Zertifikat denselben Subjektnamen und denselben öffentlichen Schlüssel wie das alte Zertifikat enthält, daher ist die Signatur auf dem Endzertifikat gültig. Firefox ist schlau genug, um beide Optionen auszuprobieren, bis er das funktionierende findet, sodass die Add-ons wieder überprüft werden. Beachten Sie, dass dies die gleiche Logik ist, die wir zur Überprüfung von TLS-Zertifikaten verwenden.
Hinweis des Autors: Leser, die mit WebPKI vertraut sind, werden feststellen, dass genau dies auch für Cross-Zertifikate gilt.
Das Bemerkenswerteste an dieser Lösung ist, dass sie nicht erfordert, dass bestehende Add-ons neu signiert werden. Sobald der Browser das neue Zertifikat erhält, werden alle Add-ons wieder funktionieren. Es bleibt die Herausforderung, das neue Zertifikat automatisch und remote an die Nutzer zu liefern und Firefox zu zwingen, die deaktivierten Add-ons erneut zu überprüfen.
Normandy und das Forschungssystem
Ironischerweise wird dieses Problem durch ein spezielles Add-on gelöst, das als "systematisch" bezeichnet wird. Um Forschungen durchzuführen, haben wir ein System namens Normandy entwickelt, das Forschungen an die Nutzer liefert. Diese Forschungen werden automatisch im Browser ausgeführt und haben erweiterten Zugriff auf die internen APIs von Firefox. Forschungen können neue Zertifikate im Zertifikatspeicher hinzufügen.
Hinweis des Autors: Wir fügen das Zertifikat nicht mit besonderen Berechtigungen hinzu; es ist mit einem Root-Zertifikat signiert, sodass Firefox ihm vertraut. Wir fügen es einfach dem Pool von Zertifikaten hinzu, die vom Browser verwendet werden können.
Daher besteht die Lösung darin, eine Forschung zu erstellen:
- welche den von uns erstellten neuen Zertifikat bei den Nutzern installiert
- die den Browser zwingt, die deaktivierten Add-ons erneut zu überprüfen, damit sie wieder funktionieren
"Aber warte", wirst du sagen, "die Add-ons funktionieren nicht, wie sollen wir das systematische Add-on starten?" Wir signieren es mit dem neuen Zertifikat!
Lass uns alles zusammenstellen… warum dauert das so lange?
Also, der Plan: Ein neues Zertifikat zur Ersetzung des alten ausstellen, ein System-Add-on erstellen und es den Nutzern über Normandy bereitstellen. Die Probleme, wie ich bereits erwähnt habe, begannen am 4. Mai um 4:00 Uhr, und bereits um 12:44 Uhr desselben Tages, weniger als 9 Stunden später, haben wir eine Korrektur an Normandy gesendet. Es dauerte weitere 6–12 Stunden, bis es alle Nutzer erreicht hatte. Das ist schon nicht schlecht, aber die Nutzer auf Twitter fragen, warum wir nicht schneller handeln konnten.
Zunächst einmal benötigten wir Zeit, um ein neues Zwischenzertifikat auszustellen. Wie bereits oben erwähnt, wird der Schlüssel des Wurzelzertifikats sicher in einem Hardware-Sicherheitsmodul gespeichert. Das ist aus sicherheitstechnischer Sicht gut, da die Wurzel sehr selten verwendet wird und sicher geschützt bleiben muss, aber es ist etwas umständlich, wenn man dringend ein neues Zertifikat signieren muss. Einer unserer Techniker musste zum HSM-Speicher reisen. Dann gab es gescheiterte Versuche, das richtige Zertifikat auszustellen, und jeder Versuch kostete ein bis zwei Stunden, die für Tests aufgewendet wurden.
Zweitens hat die Entwicklung des System-Add-ons einige Zeit in Anspruch genommen. Konzeptuell ist es sehr einfach, aber selbst einfache Programme erfordern Sorgfalt. Wir wollten sicherstellen, dass wir die Situation nicht noch verschlimmern. Die Untersuchung muss vor dem Versand an die Nutzer getestet werden. Außerdem muss das Add-on signiert werden, aber unser System zur Signierung von Add-ons war deaktiviert, weshalb wir nach einer Umgehung suchen mussten.
Schließlich, nachdem wir die Untersuchungen zum Versand vorbereitet hatten, benötigte das Deployment Zeit. Der Browser überprüft alle 6 Stunden auf Updates von Normandy. Nicht alle Computer sind ständig eingeschaltet und mit dem Internet verbunden, daher benötigt es Zeit, bis die Korrektur unter den Nutzern verbreitet ist.
Letzte Schritte
Die Untersuchung sollte das Problem bei den meisten Nutzern beheben, ist jedoch nicht für alle verfügbar. Einige Nutzer erfordern einen besonderen Ansatz:
- Nutzer, die Untersuchungen oder Telemetrie deaktiviert haben
- Nutzer der Android-Version (Fennec), wo Untersuchungen überhaupt nicht unterstützt werden
- Nutzer von benutzerdefinierten Firefox ESR-Versionen in Unternehmen, wo die Aktivierung von Telemetrie nicht möglich ist
- Benutzer, die sich hinter MitM-Proxys befinden, da unser Add-on-Installationssystem Key-Pinning verwendet, das mit solchen Proxys nicht funktioniert.
- Benutzer veralteter Firefox-Versionen, die keine Updates unterstützen.
Wir können nichts für die letzte Benutzerkategorie tun – sie sollten auf jeden Fall auf eine neue Firefox-Version aktualisieren, da die veralteten Versionen schwerwiegende, nicht behobene Sicherheitsanfälligkeiten aufweisen. Wir wissen, dass einige Personen bei alten Firefox-Versionen bleiben, weil sie ältere Erweiterungen ausführen möchten, aber viele der alten Erweiterungen wurden bereits für die neuen Versionen des Browsers portiert. Für die anderen Benutzer haben wir einen Patch entwickelt, der das neue Zertifikat installiert. Es wurde als Bugfix-Release veröffentlicht (Hinweis des Übersetzers: Firefox 66.0.5), sodass die Benutzer es über den regulären Update-Kanal erhalten – vermutlich haben sie es bereits erhalten. Wenn Sie eine benutzerdefinierte Firefox-ESR-Build verwenden, wenden Sie sich bitte an Ihren Maintainer.
Wir verstehen, dass das alles nicht ideal ist. In einigen Fällen haben Benutzer Daten von Erweiterungen verloren (zum Beispiel die Daten der Erweiterung Multi-Account-Container).
Dieses Nebenwirkung konnte nicht vermieden werden, aber wir glauben, dass wir kurzfristig die beste Lösung für die meisten Benutzer gewählt haben. Langfristig werden wir nach anderen, ausgefeilteren architektonischen Ansätzen suchen.
Lektionen
Zunächst hat unser Team großartige Arbeit geleistet, indem es weniger als 12 Stunden nach der Entdeckung des Problems einen Fix erstellt und bereitgestellt hat. Als jemand, der an den Besprechungen teilgenommen hat, kann ich sagen, dass die Leute in dieser schwierigen Situation sehr hart gearbeitet haben und nur wenig Zeit ungenutzt blieb.
Es ist offensichtlich, dass das alles nicht hätte passieren sollen. Es ist klar, dass wir unsere Prozesse anpassen müssen, um die Wahrscheinlichkeit ähnlicher Vorfälle zu verringern und die Folgen zu erleichtern.
In der nächsten Woche werden wir einen offiziellen Post-Mortem und eine Liste der Änderungen veröffentlichen, die wir beabsichtigen vorzunehmen. Bis dahin möchte ich meine Gedanken teilen. Erstens sollte es einen besseren Weg geben, den Status dessen zu verfolgen, was eine potenzielle Zeitbombe ist. Wir müssen sicherstellen, dass wir nicht in eine Situation geraten, in der eine von ihnen plötzlich auslöst. Wir arbeiten noch an den Details, aber mindestens sollten wir eine Erfassung aller derartigen Dinge durchführen.
Zweitens benötigen wir einen Mechanismus zur schnellen Zustellung von Updates an die Benutzer, selbst dann, wenn – insbesondere wenn – alles andere nicht funktioniert. Es war großartig, dass wir das System der 'Umfragen' nutzen konnten, aber es ist ein unvollkommenes Instrument und hat einige unerwünschte Nebeneffekte. Insbesondere wissen wir, dass bei vielen Benutzern die automatische Aktualisierung aktiviert ist, sie aber lieber nicht an Umfragen teilnehmen würden (ich gebe zu, ich habe diese auch deaktiviert!). Gleichzeitig benötigen wir eine Möglichkeit, Updates an die Benutzer zu senden, wobei die technische Umsetzung intern, die Benutzer die Möglichkeit haben sollten, Updates zu abonnieren (einschließlich Notfallkorrekturen), aber all das andere abzulehnen. Darüber hinaus sollte der Update-Kanal reaktionsschneller sein als jetzt. Selbst am 6. Mai gab es noch Benutzer, die weder die Korrektur noch die neue Version genutzt haben. An diesem Problem wurde bereits gearbeitet, aber das, was passiert ist, hat gezeigt, wie wichtig es ist.
Schließlich werden wir uns die Sicherheitsarchitektur der Erweiterungen ansehen, um sicherzustellen, dass sie ein angemessenes Sicherheitsniveau mit minimalem Risiko für Fehler bietet.
In der nächsten Woche werden wir die Ergebnisse einer genaueren Analyse des Geschehens betrachten, und bis dahin beantworte ich gerne Fragen per E-Mail: ekr-blog@mozilla.com
Quelle: linux.org.ru
