Remarque du traducteur : pour le confort des lecteurs, les dates sont données selon l'heure de Moscou
Récemment, nous avons manqué le moment d'expiration d'un des certificats utilisés pour signer les extensions. Cela a entraîné la désactivation des extensions pour les utilisateurs. Maintenant que la plupart des problèmes sont résolus, j'aimerais parler des détails de ce qui s'est passé et du travail que nous avons accompli.
Contexte : extensions et signatures
Les modules complémentaires installés doivent avoir une signature numérique, qui protège les utilisateurs contre les modules complémentaires malveillants, et exige un minimum de vérification des modules complémentaires par les employés de Mozilla. Nous avons introduit cette exigence en 2015, car nous rencontrions de graves problèmes avec des modules complémentaires malveillants.
Comment cela fonctionne : chaque copie de Firefox contient un « certificat racine ». La clé de ce « racine » est stockée dans un module de protection matériel (HSM), qui n'a pas accès au réseau. Tous les quelques années, cette clé signe un nouveau « certificat intermédiaire », qui est utilisé pour signer les modules complémentaires. Lorsque le développeur soumet un module complémentaire, nous créons un « certificat final » temporaire et le signons en utilisant le certificat intermédiaire. Ensuite, le module complémentaire lui-même est signé avec le certificat final. Schématiquement, cela ressemble à ceci.
Notez que chaque certificat a un « sujet » (à qui le certificat est délivré) et un « émetteur » (qui a délivré le certificat). Dans le cas du certificat racine, « sujet » = « émetteur », mais pour d'autres certificats, l'émetteur du certificat est le sujet du certificat supérieur qui l'a signé.
Point important : chaque module complémentaire est signé avec un certificat final unique, mais presque toujours ces certificats finaux sont signés par le même certificat intermédiaire.
Remarque de l'auteur : une exception — les modules complémentaires très anciens. À l'époque, différents certificats intermédiaires étaient utilisés.
Ce certificat intermédiaire a posé des problèmes : chaque certificat est valide pendant une certaine période. Avant ou après cette période, le certificat est invalide et le navigateur n'utilisera pas les extensions signées avec ce certificat. Malheureusement, le certificat intermédiaire a expiré le 4 mai à 4 heures du matin.
Les conséquences ne se sont pas faites sentir immédiatement. Firefox vérifie les signatures des extensions installées non pas en continu, mais environ toutes les 24 heures, et le moment de la vérification est différent pour chaque utilisateur. Par conséquent, certaines personnes ont rencontré des problèmes immédiatement, tandis que d'autres beaucoup plus tard. Nous avons été informés du problème à peu près au moment où le certificat a expiré et avons immédiatement commencé à chercher une solution.
Réduire les dommages
Dès que nous avons compris ce qui s'était passé, nous avons essayé d'éviter d'aggraver la situation.
Tout d'abord, nous avons cessé d'accepter et de signer de nouvelles extensions. Il n'est pas utile d'utiliser un certificat expiré pour cela. Avec le recul, je dirais qu'il aurait été possible de laisser les choses telles qu'elles étaient. La réception des extensions a été reprise maintenant.
Deuxièmement, nous avons immédiatement envoyé un correctif qui a empêché la vérification quotidienne des signatures. De cette manière, nous avons sauvé les utilisateurs dont le navigateur n'avait pas encore vérifié les extensions au cours des dernières 24 heures. Ce correctif a maintenant été révoqué, car il n'est plus nécessaire.
Travail parallèle
En théorie, la solution au problème semble simple : créer un nouveau certificat intermédiaire valide et re-signer chaque extension. Malheureusement, cela ne fonctionnera pas :
- nous ne pouvons pas rapidement re-signer 15 000 extensions en même temps, le système n'est pas conçu pour une telle charge
- une fois que nous aurons signé les extensions, les versions mises à jour devront être livrées aux utilisateurs. La plupart des extensions sont installées depuis les serveurs de Mozilla, donc dans les prochaines 24 heures, Firefox trouvera des mises à jour, mais certains développeurs distribuent des extensions signées par des canaux tiers, donc les utilisateurs devraient mettre à jour ces extensions manuellement
Au lieu de cela, nous avons essayé de développer un correctif qui atteindrait tous les utilisateurs, sans nécessiter (ou presque pas) d'actions de leur part.
Nous avons rapidement identifié deux stratégies principales que nous avons utilisées simultanément :
- Mettre à jour Firefox pour modifier la période de validité du certificat. Cela fera miraculeusement fonctionner à nouveau les extensions existantes, mais nécessitera la publication et la livraison d'un nouveau build de Firefox.
- Créer un certificat valide et d'une manière ou d'une autre convaincre Firefox de l'accepter à la place de l'existant, dont la date d'expiration est dépassée.
Nous avons décidé de commencer par la première option, qui semblait parfaitement fonctionnelle. À la fin de la journée, nous avons publié une deuxième correction (un nouveau certificat), dont nous parlerons plus tard.
Remplacement du certificat
Comme je l'ai mentionné précédemment, il était nécessaire de :
- créer un nouveau certificat valide
- l'installer à distance dans Firefox
Pour comprendre pourquoi cela fonctionnera, examinons de plus près le processus de vérification de l'extension. L'extension elle-même est fournie sous la forme d'un ensemble de fichiers, y compris la chaîne de certificats utilisés pour la signature. Ainsi, l'extension peut être vérifiée si le navigateur connaît le certificat racine, qui est intégré dans Firefox lors de la construction. Cependant, comme nous le savons déjà, le certificat intermédiaire est expiré, donc l'extension ne peut pas être vérifiée.
Lorsque Firefox tente de vérifier l'extension, il ne se limite pas à utiliser les certificats contenus à l'intérieur de l'extension elle-même. Au lieu de cela, le navigateur essaie de créer une chaîne de certificats valide, en commençant par le certificat final et en continuant jusqu'à atteindre la racine. Au premier niveau, nous commençons par le certificat final, puis nous trouvons le certificat dont le sujet est l'éditeur du certificat final (c'est-à-dire, le certificat intermédiaire). Ce certificat intermédiaire est généralement fourni avec l'extension, mais tout certificat du magasin du navigateur peut également jouer ce rôle. Si nous pouvons ajouter à distance un nouveau certificat valide dans le magasin de certificats, Firefox essaiera de l'utiliser. Situation avant et après l'installation du nouveau certificat.
Après l'installation d'un nouveau certificat, Firefox aura deux options lors de la vérification de la chaîne de certificats : utiliser l'ancien certificat invalide (qui ne fonctionnera pas), ou le nouveau certificat valide (qui fonctionnera). Il est important que le nouveau certificat contienne le même nom de sujet et la même clé publique que l'ancien certificat, donc sa signature sur le certificat final sera valide. Firefox est suffisamment intelligent pour essayer les deux options jusqu'à ce qu'il trouve celle qui fonctionne, garantissant ainsi que les extensions seront vérifiées à nouveau. Notez que c'est la même logique que nous utilisons pour vérifier les certificats TLS.
Note de l'auteur : les lecteurs familiers avec WebPKI remarqueront que les certificats croisés fonctionnent de la même manière.
La meilleure chose à propos de cette solution est qu'elle ne nécessite pas de réinscription des extensions existantes. Une fois que le navigateur obtient le nouveau certificat, toutes les extensions fonctionneront à nouveau. Reste le défi de livrer le nouveau certificat aux utilisateurs (automatiquement et à distance), ainsi que de forcer Firefox à revérifier les extensions désactivées.
Normandy et le système de recherche
Ironie du sort, ce problème est résolu par une extension spéciale appelée « système ». Pour mener des recherches, nous avons développé un système appelé Normandy, qui livre des enquêtes aux utilisateurs. Ces enquêtes s'exécutent automatiquement dans le navigateur et ont un accès étendu aux API internes de Firefox. Les études peuvent ajouter de nouveaux certificats au magasin de certificats.
Note de l'auteur : nous n'ajoutons pas le certificat avec des privilèges spéciaux ; il est signé par le certificat d'autorité racine, donc Firefox lui fait confiance. Nous l'ajoutons simplement au pool de certificats qui peuvent être utilisés par le navigateur.
Ainsi, la solution consiste à créer une enquête :
- installant le nouveau certificat que nous avons créé pour les utilisateurs
- forçant le navigateur à revérifier les extensions désactivées afin qu'elles fonctionnent à nouveau
« Mais attendez », allez-vous dire, « les extensions ne fonctionnent pas, comment lancer une extension système ? ». Nous allons la signer avec le nouveau certificat !
Mettons tout ensemble... pourquoi cela prend-il si longtemps ?
Donc, le plan : émettre un nouveau certificat pour remplacer l'ancien, créer un module système et l'installer pour les utilisateurs via Normandy. Les problèmes, comme je l'ai dit, ont commencé le 4 mai à 4h00, et déjà à 12h44 le même jour, moins de 9 heures plus tard, nous avons envoyé la correction à Normandy. Il a fallu encore 6 à 12 heures pour qu'elle atteigne tous les utilisateurs. Ce n'est pas mal, mais les utilisateurs sur Twitter demandent pourquoi nous n'avons pas pu agir plus vite.
Tout d'abord, il a fallu du temps pour émettre un nouveau certificat intermédiaire. Comme je l'ai mentionné précédemment, la clé du certificat racine est stockée hors ligne dans un module de sécurité matériel. C'est bien du point de vue de la sécurité, car la racine est utilisée très rarement et doit être protégée de manière fiable, mais c'est un peu ennuyeux quand on a besoin d'émettre d'urgence un nouveau certificat. Un de nos ingénieurs a dû se rendre au stockage HSM. Ensuite, il y a eu des tentatives infructueuses de délivrer le bon certificat, chaque tentative coûtant une à deux heures de tests.
Deuxièmement, le développement du module système a également pris du temps. Conceptuellement, c'est très simple, mais même des programmes simples nécessitent de l'attention. Nous voulions nous assurer que nous ne rendions pas la situation pire. La recherche doit être testée avant d'être envoyée aux utilisateurs. De plus, le module doit être signé, mais notre système de signature des modules était désactivé, ce qui a nécessité de trouver un moyen de contourner cette situation.
Enfin, une fois que nous avons préparé la recherche pour l'envoi, le déploiement a pris du temps. Le navigateur vérifie les mises à jour de Normandy toutes les 6 heures. Tous les ordinateurs ne sont pas toujours allumés et connectés à Internet, il faut donc du temps pour que la correction se propage parmi les utilisateurs.
Étapes finales
La recherche devrait corriger le problème pour la plupart des utilisateurs, mais elle n'est pas disponible pour tout le monde. Certaines utilisateurs nécessitent une approche particulière :
- les utilisateurs qui ont désactivé les recherches ou la télémétrie
- les utilisateurs de la version Android (Fennec), où les recherches ne sont pas prises en charge
- les utilisateurs de versions personnalisées de Firefox ESR en entreprise, où la télémétrie ne peut pas être activée
- les utilisateurs derrière un proxy MitM, car notre système d'installation d'extensions utilise un verrouillage de clé (key pinning), qui ne fonctionne pas avec de tels proxies
- les utilisateurs des anciennes versions de Firefox, qui ne prennent pas en charge les recherches
Nous ne pouvons rien faire pour cette dernière catégorie d'utilisateurs — ils devraient absolument mettre à jour vers la nouvelle version de Firefox, car les versions obsolètes présentent d'importantes vulnérabilités non corrigées. Nous savons que certaines personnes restent sur de vieilles versions de Firefox parce qu'elles souhaitent exécuter de vieilles extensions, mais beaucoup des anciennes extensions ont déjà été portées sur les nouvelles versions du navigateur. Pour les autres utilisateurs, nous avons développé un correctif qui installera un nouveau certificat. Il a été publié comme une mise à jour de correction de bogue (note du traducteur : Firefox 66.0.5), donc les gens l'obtiendront — probablement l'ont déjà reçu — via le canal de mise à jour habituel. Si vous utilisez une version personnalisée de Firefox ESR, veuillez contacter votre mainteneur.
Nous comprenons que tout cela n'est pas idéal. Dans certains cas, les utilisateurs ont perdu des données d'extensions (par exemple, les données de l'extension Multi-Account Containers).
Ce phénomène secondaire n'a pas pu être évité, mais nous pensons que nous avons choisi la meilleure solution à court terme pour la majorité des utilisateurs. À long terme, nous rechercherons d'autres approches architecturales plus avancées.
Leçons
Tout d'abord, notre équipe a fait un travail incroyable en créant et en envoyant le correctif en moins de 12 heures après la découverte du problème. En tant que personne présente lors des réunions, je peux dire qu'en cette situation complexe, les gens ont travaillé très dur et peu de temps a été perdu en vain.
Il est évident que tout cela n'aurait jamais dû se produire. Il est clairement nécessaire de corriger nos processus pour réduire la probabilité de tels incidents et faciliter la correction des conséquences.
La semaine prochaine, nous publierons un post-mortem officiel et une liste des modifications que nous prévoyons d'apporter. En attendant, je souhaite partager mes réflexions. Tout d'abord, il devrait y avoir un meilleur moyen de suivre l'état de ce qui pourrait être une bombe à retardement. Nous devons nous assurer que nous ne nous retrouvons pas dans une situation où l'un d'eux explose soudainement. Nous travaillons encore sur les détails, mais au minimum, nous devons tenir un inventaire de toutes ces choses.
Deuxièmement, un mécanisme de livraison rapide des mises à jour aux utilisateurs est nécessaire, même lorsque — surtout lorsque — tout le reste ne fonctionne pas. C'était formidable que nous puissions utiliser le système de « sondages », mais c'est un outil imparfait et il a certains effets secondaires indésirables. En particulier, nous savons que de nombreux utilisateurs ont les mises à jour automatiques activées, mais ils préféreraient ne pas participer aux sondages (je dois admettre que moi aussi, je les ai désactivés !). En même temps, nous avons besoin d'un moyen d'envoyer des mises à jour aux utilisateurs, mais quel que soit le moyen technique interne, les utilisateurs doivent avoir la possibilité de s'abonner aux mises à jour (y compris les correctifs urgents) tout en se désinscrivant de tout le reste. De plus, le canal de mise à jour doit être plus réactif qu'il ne l'est actuellement. Même le 6 mai, il y avait encore des utilisateurs qui n'avaient pas bénéficié de la moindre mise à jour ou de la nouvelle version. Ce problème a déjà été travaillé, mais ce qui s'est passé a montré à quel point il est important.
Enfin, nous allons examiner l'architecture de sécurité des modules complémentaires pour nous assurer qu'elle garantit un niveau de sécurité adéquat avec un risque minimal de causer des dysfonctionnements.
La semaine prochaine, nous examinerons les résultats d'une analyse plus approfondie de ce qui s'est passé, mais en attendant, je serais heureux de répondre à vos questions par e-mail : ekr-blog@mozilla.com
Source : linux.org.ru
