Note. traducteur : pour la commodité des lecteurs, les dates sont données en heure de Moscou
Nous avons récemment raté la date d'expiration de l'un des certificats utilisés pour signer les modules complémentaires. Cela a entraîné la désactivation des modules complémentaires pour les utilisateurs. Maintenant que la majeure partie du problème est résolue, je voudrais partager les détails de ce qui s'est passé et du travail effectué.
Contexte : ajouts et signatures
Les modules complémentaires installés doivent avoir signature numérique, qui protège les utilisateurs contre les modules complémentaires malveillants et nécessite un examen minimal des modules complémentaires par les employés de Mozilla. Nous avons introduit cette exigence en 2015 alors que nous testions Problèmes sérieux avec des extensions malveillantes.
Comment ça marche : Chaque copie de Firefox contient un "certificat racine". La clé de cette "racine" est stockée dans Module de sécurité matériel (HSM)qui n'a pas accès au réseau. Toutes les quelques années, un nouveau "certificat intermédiaire" est signé avec cette clé, qui est utilisée lors de la signature des modules complémentaires. Lorsqu'un développeur soumet un module complémentaire, nous créons un "certificat de fin" temporaire et le signons à l'aide du certificat intermédiaire. Ensuite, l'add-on lui-même est signé par le certificat final. schématiquement ça ressemble à ça.
Notez que chaque certificat a un "sujet" (à qui le certificat a été délivré) et un "émetteur" (qui a délivré le certificat). Dans le cas d'un certificat racine, "subject" = "issuer", mais pour les autres certificats, l'émetteur d'un certificat est le sujet du certificat parent qui l'a signé.
Un point important : chaque ajout est signé par un certificat de fin unique, mais presque toujours ces certificats de fin sont signés par le même certificat intermédiaire.
Note de l'auteur : l'exception concerne les ajouts très anciens. Divers certificats intermédiaires ont été utilisés à cette époque.
Ce certificat intermédiaire a posé des problèmes : chaque certificat est valable pour une certaine période. Avant ou après cette période, le certificat est invalide et le navigateur n'utilisera pas les modules complémentaires signés avec ce certificat. Malheureusement, le certificat provisoire a expiré le 4 mai à 4 h du matin.
Les conséquences ne sont pas apparues immédiatement. Firefox vérifie les signatures des modules complémentaires installés non pas tout le temps, mais environ une fois toutes les 24 heures, et l'heure de vérification est individuelle pour chaque utilisateur. En conséquence, certaines personnes ont des problèmes immédiatement, d'autres beaucoup plus tard. Nous avons pris conscience du problème pour la première fois au moment où le certificat a expiré et avons immédiatement commencé à chercher une solution.
Nous réduisons les dégâts
Une fois que nous avons réalisé ce qui s'était passé, nous avons essayé d'empêcher la situation d'empirer.
Premièrement, ils ont cessé d'accepter et de signer de nouveaux ajouts. Cela n'a aucun sens d'utiliser un certificat expiré pour cela. Avec le recul, je dirais qu'il serait possible de tout laisser tel quel. L'acceptation des ajouts a maintenant repris.
Deuxièmement, ils ont immédiatement envoyé un correctif qui empêchait la vérification quotidienne des signatures. Ainsi, nous avons sauvé les utilisateurs dont le navigateur n'a pas eu le temps de vérifier les modules complémentaires au cours des dernières XNUMX heures. Ce correctif a maintenant été retiré et n'est plus nécessaire.
Travail parallèle
Théoriquement, la solution au problème semble simple : créer un nouveau certificat intermédiaire valide et re-signer chaque ajout. Malheureusement, cela ne fonctionnera pas :
- on ne peut pas re-signer rapidement 15 XNUMX add-ons d'un coup, le système n'est pas conçu pour une telle charge
- après avoir signé les ajouts, les versions mises à jour doivent être livrées aux utilisateurs. La plupart des modules complémentaires sont installés à partir des serveurs Mozilla, donc Firefox trouvera des mises à jour dans les prochaines XNUMX heures, mais certains développeurs distribuent des modules complémentaires signés via des canaux tiers, de sorte que les utilisateurs devraient mettre à jour ces modules manuellement.
Au lieu de cela, nous avons essayé de développer un correctif qui atteindrait tous les utilisateurs avec peu ou pas d'action de leur part.
Assez rapidement, nous avons trouvé deux stratégies principales, que nous avons utilisées en parallèle :
- Mettez à jour Firefox pour modifier la période de validité du certificat. Cela fera fonctionner à nouveau les modules complémentaires existants comme par magie, mais nécessitera la publication et l'expédition d'une nouvelle version de Firefox.
- Générer un certificat valide et convaincre Firefox de l'accepter au lieu d'un certificat existant expiré
Nous avons décidé d'utiliser d'abord la première option, qui semblait assez bien fonctionner. À la fin de la journée, le deuxième correctif (nouveau certificat) a également été publié, dont nous parlerons plus tard.
Remplacement de certificat
Comme je l'ai mentionné plus haut, il fallait :
- créer un nouveau certificat valide
- installez-le à distance dans Firefox
Pour comprendre pourquoi cela fonctionnerait, examinons de plus près le processus de validation des modules complémentaires. Le module complémentaire lui-même se présente sous la forme d'un ensemble de fichiers, y compris une chaîne de certificats utilisés pour la signature. Par conséquent, le module complémentaire peut être vérifié si le navigateur connaît le certificat racine intégré à Firefox au moment de la construction. Cependant, comme nous le savons déjà, le certificat intermédiaire a expiré, il n'est donc pas possible de vérifier l'add-on.
Lorsque Firefox tente de valider un module complémentaire, il ne se limite pas à utiliser les certificats contenus dans le module complémentaire lui-même. Au lieu de cela, le navigateur essaie de créer une chaîne de certificats valide, en commençant par le certificat de fin et en continuant jusqu'à ce qu'il atteigne la racine. Au premier niveau, on commence par le certificat feuille, puis on trouve le certificat dont le sujet est l'émetteur du certificat feuille (c'est-à-dire le certificat intermédiaire). Habituellement, ce certificat intermédiaire est fourni avec le module complémentaire, mais tout certificat du magasin du navigateur peut également servir de certificat intermédiaire. Si nous pouvons ajouter à distance un nouveau certificat valide au magasin de certificats, Firefox essaiera de l'utiliser. Situation avant et après l'installation d'un nouveau certificat.
Une fois le nouveau certificat installé, 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 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, de sorte que sa signature sur le certificat final sera valide. Firefox est assez intelligent pour essayer les deux jusqu'à ce qu'il en trouve un qui fonctionne, de sorte que les modules complémentaires seront à nouveau vérifiés. Notez qu'il s'agit de la même logique que nous utilisons pour valider les certificats TLS.
Note de l'auteur : les lecteurs familiarisés avec WebPKI remarqueront que les certifications croisées fonctionnent exactement de la même manière.
L'avantage de ce correctif est qu'il ne vous oblige pas à signer à nouveau les modules complémentaires existants. Dès que le navigateur reçoit un nouveau certificat, tous les modules complémentaires fonctionnent à nouveau. Il reste le défi de fournir un nouveau certificat aux utilisateurs (automatiquement et à distance) et d'amener Firefox à revérifier les modules complémentaires désactivés.
La Normandie et le système de recherche
Ironiquement, ce problème est résolu par un add-on spécial appelé "système". Afin de mener des recherches, nous avons développé un système appelé Normandie qui livre la recherche aux utilisateurs. Ces explorations sont automatiquement effectuées dans le navigateur et bénéficient d'un accès amélioré aux API internes de Firefox. La recherche peut ajouter de nouveaux certificats au magasin de certificats.
Note de l'auteur : Nous n'ajoutons pas de certificat avec des privilèges spéciaux ; il est signé avec un certificat racine, donc Firefox lui fait confiance. Nous l'ajoutons simplement au pool de certificats pouvant être utilisés par le navigateur.
La solution est donc de créer une étude :
- qui installe le nouveau certificat que nous avons créé pour les utilisateurs
- obligeant le navigateur à revérifier les modules complémentaires désactivés afin qu'ils fonctionnent à nouveau
"Mais attendez," dites-vous, "les modules complémentaires ne fonctionnent pas, comment puis-je exécuter le module complémentaire système?". Signons-le avec un nouveau certificat !
Tout mettre ensemble… pourquoi cela prend-il si longtemps ?
Ainsi, le plan est d'émettre un nouveau certificat pour remplacer l'ancien, de créer un système complémentaire et de l'installer aux utilisateurs via la Normandie. 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é un correctif en Normandie. Il a fallu encore 6 à 12 heures pour qu'il atteigne tous les utilisateurs. Pas mal déjà, mais les utilisateurs de Twitter se demandent pourquoi nous n'aurions pas pu agir plus vite.
Tout d'abord, il a fallu du temps pour délivrer un nouveau certificat intermédiaire. Comme je l'ai mentionné ci-dessus, la clé du certificat racine est stockée hors ligne dans le module de sécurité matériel. C'est bien du point de vue de la sécurité, car la racine est rarement utilisée et doit être sécurisée, mais c'est un peu gênant lorsque vous devez signer un nouveau certificat en urgence. Un de nos ingénieurs a dû se rendre au stockage HSM. Ensuite, il y a eu des tentatives infructueuses pour délivrer le bon certificat, et chaque tentative valait une ou deux heures consacrées aux tests.
Deuxièmement, le développement d'un système complémentaire a pris du temps. Conceptuellement, c'est très simple, mais même des programmes simples nécessitent une attention particulière. Nous voulions nous assurer de ne pas aggraver les choses. La recherche doit être testée avant d'être envoyée aux utilisateurs. De plus, le module complémentaire doit être signé, mais notre système de signature de module complémentaire a été désactivé, nous avons donc dû rechercher une solution de contournement.
Enfin, après avoir préparé les études pour l'expédition, le déploiement a pris du temps. Le navigateur vérifie les mises à jour de la Normandie toutes les 6 heures. Tous les ordinateurs ne sont pas constamment allumés et connectés à Internet, il faut donc du temps pour que le correctif se propage aux utilisateurs.
Étapes finales
La recherche devrait résoudre le problème pour la plupart des utilisateurs, mais n'est pas disponible pour tout le monde. Certains utilisateurs nécessitent une approche particulière :
- les utilisateurs qui ont désactivé la recherche ou la télémétrie
- utilisateurs de la version Android (Fennec), où la recherche n'est pas prise en charge du tout
- les utilisateurs de versions personnalisées de Firefox ESR dans les entreprises où la télémétrie ne peut pas être activée
- les utilisateurs assis derrière des proxys MitM, car notre système d'installation complémentaire utilise l'épinglage de clé, qui ne fonctionne pas avec de tels proxys
- les utilisateurs d'anciennes versions de Firefox qui ne prennent pas en charge la recherche
Nous ne pouvons rien faire à propos de la dernière catégorie d'utilisateurs - ils devraient toujours passer à la nouvelle version de Firefox, car les versions obsolètes présentent de graves vulnérabilités non corrigées. Nous savons que certaines personnes restent sur les anciennes versions de Firefox parce qu'elles souhaitent exécuter des modules complémentaires plus anciens, mais bon nombre des modules complémentaires plus anciens ont déjà été portés sur de nouvelles versions du navigateur. Pour les autres utilisateurs, nous avons développé un patch qui installera un nouveau certificat. Il a été publié en tant que version de correction de bogues (note du traducteur : Firefox 66.0.5), afin que les gens l'obtiennent - très probablement déjà - via le canal de mise à jour normal. Si vous utilisez une version personnalisée de Firefox ESR, veuillez contacter votre responsable.
Nous comprenons que ce n'est pas idéal. Dans certains cas, les utilisateurs ont perdu des données complémentaires (par exemple, des données complémentaires Conteneurs multi-comptes).
Cet effet secondaire n'a pas pu être évité, mais nous pensons qu'à court terme, nous avons choisi la meilleure solution pour la plupart des utilisateurs. A terme, nous chercherons d'autres approches architecturales plus avancées.
Les leçons
Tout d'abord, notre équipe a fait un travail incroyable en créant et en soumettant un correctif en moins de 12 heures après avoir découvert le problème. En tant que personne qui a assisté aux réunions, je peux dire que dans cette situation difficile, les gens ont travaillé très fort et très peu de temps a été perdu.
De toute évidence, cela n'était pas censé se produire du tout. Il est clairement utile d'ajuster 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 changements que nous avons l'intention d'apporter. Pour l'instant, je vais partager mes pensées. Premièrement, il doit y avoir un meilleur moyen de suivre l'état de ce qui est une bombe à retardement potentielle. Nous devons nous assurer que nous ne nous retrouvons pas dans une situation où l'un d'eux fonctionne soudainement. Nous travaillons toujours sur les détails, mais au minimum, nous devons tenir compte de toutes ces choses.
Deuxièmement, nous avons besoin d'un mécanisme pour fournir rapidement des mises à jour aux utilisateurs, même lorsque - surtout lorsque - tout le reste ne fonctionne pas. C'était bien que nous ayons pu utiliser le système de "recherche", mais ce n'est pas un outil parfait et il a des effets secondaires indésirables. En particulier, nous savons que de nombreux utilisateurs ont activé les mises à jour automatiques, mais ils préfèrent ne pas participer à la recherche (j'avoue, je les ai également désactivées !). Dans le même temps, nous avons besoin d'un moyen d'envoyer des mises à jour aux utilisateurs, mais quelle que soit la mise en œuvre technique interne, les utilisateurs doivent pouvoir s'abonner aux mises à jour (y compris les correctifs) mais se désinscrire de tout le reste. De plus, le canal de mise à jour devrait être plus réactif qu'il ne l'est actuellement. Même le 6 mai, il y avait encore des utilisateurs qui ne profitaient ni du correctif ni 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 examinerons l'architecture de sécurité des modules complémentaires pour nous assurer qu'elle offre le bon niveau de sécurité avec un risque minimal de casser quelque chose.
La semaine prochaine, nous examinerons les résultats d'une analyse plus approfondie de ce qui s'est passé, mais en attendant, je serai heureux de répondre aux questions par e-mail : [email protected]
Source: linux.org.ru