mercredi, 2 février 2022

Rétrospective et détails techniques sur la récente panne de Firefox

Mozilla Hacks Ce billet est une traduction de l’article écrit par Christian Holler et publié originalement sur Hacks.mozilla.org : « Retrospective and Technical Details on the recent Firefox Outage ».

Le 13 janvier 2022, Firefox a été inutilisable pendant presque deux heures pour les utilisatrices et utilisateurs du monde entier. Cet incident a interrompu l’activité de nombreuses personnes. Ce billet met en lumière la séquence d’évènements complexe et les circonstances qui, combinées, ont déclenché un bug profondément enfoui dans le code réseau de Firefox.

Que s’est-il passé ?

Firefox dispose de plusieurs serveurs et d’une infrastructure gérant plusieurs services internes. Ceux-ci incluent les mises à jour, la télémétrie, la gestion des certificats, les rapports de plantage et d’autres fonctionnalités analogues. Cette infrastructure est hébergée par différents fournisseurs de services dans le cloud qui utilisent des répartiteurs de charge afin d’équilibrer la charge entre les serveurs. Pour ces services hébergés sur Google Cloud Platform (GCP), ces répartiteurs de charge possèdent des paramètres relatifs au protocole HTTP qu’ils doivent communiquer. L’un de ces paramètres concerne la prise en charge de HTTP/3 et dispose de trois états : « Activé », « Désactivé » ou « Automatique (par défaut) ». Nos répartiteurs de charge étaient réglés sur « Automatique (par défaut) » et le 13 janvier 2022 à 07 h 28 UTC, GCP a déployé un changement imprévu pour utiliser HTTP/3 par défaut. Firefox utilisant HTTP/3 lorsqu’il est pris en charge, à partir de cet instant, certaines connexions de Firefox à l’infrastructure de services ont utilisé HTTP/3 plutôt que le protocole HTTP/2, utilisé jusqu’alors.

Peu après, nous avons remarqué un pic de plantages via notre outil de rapport sur les plantages et nous avons également reçu différents signalements, tant à l’intérieur qu’à l’extérieur de Mozilla, décrivant l’absence de réponse du navigateur.

Graphe des rapports d’erreur montrant un pic vers 300 000

La file des rapports de plantage à traiter a augmenté jusqu’à atteindre environ 300 000 rapports non traités.

Lors de la procédure de réponse à incident, nous avons rapidement découvert que le client plantait au sein d’une requête réseau vers un des services internes de Firefox. Toutefois, nous n’avions aucune explication sur la raison du déclenchement de ce problème à cet instant, ni sur sa portée. Nous avons continué à chercher l’élément déclencheur : un changement avait dû se produire pour que le problème commence. Nous avons déterminé que nous n’avions pas diffusé des mises à jour ou des changements de configuration qui auraient pu causer ce problème. En même temps, nous gardions en tête que HTTP/3 était activé depuis Firefox 88 et était activement utilisé par certains sites web populaires.

Bien que nous ne puissions pas le voir, nous suspections alors un genre de changement « invisible » déployé par l’un de nos fournisseurs qui aurait modifié, d’une façon ou d’une autre, le comportement des répartiteurs de charge. Après un examen approfondi, aucun de nos paramètres n’avait changé. Nous avons alors découvert, grâce aux journaux, que, pour une raison inconnue, les répartiteurs de charge pour notre service de télémétrie servaient désormais des connexions HTTP/3 alors qu’ils ne le faisaient pas auparavant. Nous avons désactivé de façon explicite HTTP/3 sur GCP à 09 h 12 UTC. Cela a débloqué nos utilisatrices et utilisateurs, mais nous n’étions pas certains de la cause principale, et sans la connaître, il nous était impossible de dire si cela aurait un impact sur d’autres connexions HTTP/3.

¹ Certains services hautement critiques, comme les mises à jour, utilisent un marqueur spécial, beConservative, qui empêche l’utilisation de toute technologie pour leurs connexions (par exemple HTTP/3).

Un cocktail d’ingrédients spéciaux

Il est vite devenu clair que certaines circonstances particulières devaient être réunies pour que le plantage se produise. Nous avons réalisé différents tests avec plusieurs outils et services distants et nous ne sommes pas parvenus à reproduire le problème, même avec une connexion normale au serveur de recette pour la télémétrie (un serveur uniquement utilisé pour tester les déploiements, que nous avions laissé avec sa configuration originale à des fins de tests). Avec Firefox, en revanche, nous pouvions reproduire le problème avec le serveur de recette.

En déboguant, nous avons trouvé « l’ingrédient secret » qui nous manquait pour que le bug se produise. Toutes les connexions HTTP/3 passaient par Necko, notre pile réseau. Toutefois, les composants Rust qui ont besoin d’un accès direct au réseau n’utilisent pas Necko directement, ils l’appellent à travers une bibliothèque intermédiaire intitulée viaduct.

Pour comprendre l’intérêt de cette nuance, nous devons d’abord comprendre certains aspects internes de Necko et notamment les requêtes d’upload HTTP/3. Pour de telles requêtes, les API haut niveau de Necko vérifient si l’en-tête Content-Length est présent et, s’il ne l’est pas, l’ajoutent automatiquement. Le code HTT/3 de plus bas niveau repose ensuite sur ce traitement afin de déterminer la taille de la requête. Cela fonctionne correctement pour le contenu web et les autres requêtes de notre code.

En revanche, lorsque les requêtes passent d’abord par viaduct, ce dernier convertira en minuscules chaque en-tête avant de le passer à Necko. Et c’est là qu’est le problème : les vérifications d’API de Necko ne sont pas sensibles à la casse tandis que le code bas niveau pour HTTP/3 est sensible à la casse. Ainsi, si du code ajoutait l’en-tête Content-Length et passait la requête via viaduct, celle-ci passerait les vérifications des API Necko mais le code HTTP/3 ne trouverait pas l’en-tête.

En l’occurrence, le module de télémétrie est actuellement le seul composant de Firefox sur ordinateur à base de Rust qui utilise la pile réseau et qui ajoute un en-tête Content-Length. C’est pour cela que les personnes qui ont désactivé la télémétrie ont vu le problème résolu bien qu’il ne soit pas lié à la fonctionnalité de télémétrie même et qu’il aurait pu être déclenché par ailleurs.

Un diagramme montrant les différents composants réseau dans Firefox.

Un chemin de code spécifique était nécessaire pour déclencher le problème dans l’implémentation du protocole HTTP/3.

² Il s’agit d’API internes, qui ne sont pas accessibles depuis le contenu web.

La boucle infinie

Nous avons : le changement sur les répartiteurs de charge qui est en place, un chemin de code spécifique dans un nouveau service Rust désormais actif. Il reste l’ingrédient final pour déclencher le problème auprès des utilisateurs et utilisatrices qui était plongé dans le code HTTP/3 de Necko.

Lors de la gestion d’une requête, le code cherchait l’en-tête de façon sensible à la casse et échouait lorsque l’en-tête avait été mis en minuscules par viaduct. Sans l’en-tête, la requête était considérée comme complète par le code de Necko, le corps de la requête n’était alors pas envoyé. Toutefois, ce code ne finissait son exécution lorsqu’il n’y avait plus de contenu supplémentaire à envoyer. Cet état inattendu a provoqué une boucle infinie plutôt que de déclencher une erreur. Comme l’ensemble des requêtes réseau passent par un seul thread de socket, cette boucle bloquait toute communication réseau ultérieure, rendant Firefox sans réaction, incapable de charger du contenu web.

Les leçons apprises

Comme c’est souvent le cas, le problème était beaucoup plus complexe que ce qu’il paraissait à première vue et de nombreux facteurs contributifs ont été réunis. Certains des facteurs principaux que nous avons identifiés comprennent :

  • Le déploiement imprévu de HTTP/3 par défaut par GCP. Nous travaillons activement avec eux afin d’améliorer la situation. Nous avons conscience qu’une annonce (comme c’est généralement le cas) n’aurait pas complètement réduit le risque d’incident. Elle aurait en revanche déclenché des expérimentations (par exemple avec un environnement de recette) et un déploiement plus contrôlés.
  • Le paramètre « Automatique (par défaut) » de nos répartiteurs de charge, plutôt qu’un choix explicite, a permis que ce déploiement ait lieu automatiquement. Nous passons en revue toutes les configurations de nos services pour éviter des erreurs similaires à l’avenir.
  • La combinaison particulière de HTTP/3 et de viaduct sur Firefox pour ordinateur n’était pas couverte par notre système d’intégration continue. Bien que nous ne puissions pas tester l’ensemble des combinaisons de configurations et de composants possibles, le choix de la version de HTTP est un changement plutôt majeur qui aurait dû être testé. Il en va de même de l’utilisation d’une couche réseau supplémentaire comme viaduct. Les tests HTTP/3 actuels couvrent le comportement bas niveau et celui de Necko tel qu’ils sont utilisés pour du contenu web. Nous devrions exécuter plus de tests systèmes avec différentes versions de HTTP, cela aurait pu révéler ce problème.

Nous étudions également un plan d’action pour que le navigateur soit plus résilient face à de tels problèmes et pour que la réponse à incident soit plus rapide. Apprendre le plus possible de cet incident nous aidera à améliorer la qualité de nos produits. Nous remercions toutes les personnes qui ont envoyé leurs rapports de plantage, qui ont travaillé avec nous sur Bugzilla ou qui ont aidé les autres à contourner le problème.

À propos de Christian Holler

Christian est responsable technique de Firefox et ingénieur sécurité expérimenté à Mozilla.


Merci à Mozinet et cajuteq pour la relecture !

Comme la version originale, cette traduction est disponible sous la licence CC By-SA 3.0.

mardi, 16 mars 2021

MDN sur GitHub, comment contribuer ?

Schéma d'organisation des depôts Git pour MDN, mar. 2021

MDN Web Docs est un site collaboratif qui documente les différentes technologies web, de HTML à CSS en passant par JavaScript, HTTP, les différentes API (DOM, WebGL, etc.). Pendant de nombreuses années, le contenu de MDN était organisé dans une base de données et éditable page par page via un éditeur sur le site. Fin 2020, MDN a effectué une mue et si le site n’a pas changé d’adresse, le contenu sous-jacent réside désormais sur GitHub : toute la documentation est contenue dans un dépôt Git. Après une période de gel hivernal, la localisation est aujourd’hui de nouveau possible (ce billet fait suite au précédent). Bref, la méthode de contribution et les outils associés ont bien changé. Voyons ce qu’il en est ici.

Lire la suite

mardi, 8 décembre 2020

Mise à jour à propos de la stratégie de localisation de MDN

MDN web docs Mozilla : Des ressources pour les développeurs, par les développeurs.

MDN web docs Mozilla : Des ressources pour les développeurs, par les développeurs. Cet article est une traduction d’An update on MDN Web Docs’ localization strategy, écrit par Chris Mills. Si vous souhaitez contribuer aux traductions de MDN en français, venez nous faire signe sur le salon #l10n-fr !

Lire la suite

lundi, 2 septembre 2019

Les types d'interfaçage WebAssembly : une interopérabilité pour les unir tous

4 personnages représentant Python, Ruby, Rust et C++ disent : Nous aimons la vitesse de WebAssembly, la sécurité qu'il pourrait nous apporter et nous souhaitons tous que les développeurs puissent travailler efficacement

Cet article est une traduction de WebAssembly Interface Types: Interoperate with All the Things!, écrit par Lin Clark. Merci à elle pour le travail de rédaction originale !

Lire la suite

vendredi, 10 mai 2019

Détails techniques sur la panne des modules complémentaires de Firefox

Illustration des liens de signatures entre les certificats et les modules

Cet article est une traduction de Technical Details on the Recent Firefox Add-on Outage, écrit par Eric Rescorla, directeur technique de l’équipe de Firefox. Pour un aperçu moins technique, vous pouvez lire cet article. Merci à Vincent pour la relecture !


Il y a quelques jours, Firefox a rencontré un problème empêchant la plupart des modules complémentaires de fonctionner. Nous avons commis une erreur en laissant expirer un des certificats utilisés pour la signature des modules. Cela a eu pour effet de désactiver une majeure partie des modules. Maintenant que ce problème a été corrigé pour la plupart des utilisateurs et que la plupart des modules sont revenus à la normale, nous souhaitions revenir sur les détails de ce problème, les raisons de son origine et la façon dont nous l’avons résolu.

Lire la suite

dimanche, 19 août 2018

Retrait de la confiance envers les certificats TLS de Symantec

Sites avec certificat émis par Symantec dans Chrome Canary à gauche et Firefox Nightly à droite
Sites avec certificat émis par Symantec dans Chrome Canary à gauche et Firefox Nightly à droiteSites avec certificat émis par Symantec
dans Chrome Canary à gauche
et Firefox Nightly à droite

La plupart des grands éditeurs de navigateurs ont annoncé des plans, qui arrivent rapidement à échéance, pour retirer la confiance accordée aux certificats émis par Symantec. Les admins de sites web dont la navigation sécurisée (HTTPS) repose sur de tels certificats doivent en changer rapidement, faute de quoi leurs sites ne vont rapidement plus s’afficher dans la plupart des navigateurs. La communauté Mozilla francophone a traduit le billet du blog Sécurité de Mozilla expliquant l’urgence de cette action.

 

Les utilisateurs et utilisatrices de Firefox Nightly peuvent aider à la transition en contactant les canaux de communication ou d’assistance des sites qui seront affectés par ces retraits de confiance.

Lire la suite

lundi, 9 avril 2018

Une plongée illustrée dans les modules ECMAScript

Cet article est une traduction de ES modules: A cartoon deep-dive, écrit par Lin Clark. Merci à goofy pour la relecture !

Lire la suite

lundi, 21 août 2017

IntersectionObserver arrive dans Firefox

Illustration d'un élément cible avec une intersection partielle sur le viewport du navigateur

Cet article est la traduction de Intersection Observer comes to Firefox, écrit par Dan Callahan et publié sur le blog Hacks. La version anglaise est disponible ici. Merci à Marie Destandau pour cette traduction !


Lire la suite

mercredi, 21 juin 2017

Bienvenue au MozFest de Londres

MozFest : photo de groupe

MozFest : photo de groupeLe MozFest, pour Mozilla Festival, tiendra sa 8ᵉ édition à Londres cet automne. Le mouvement du Web ouvert s’y retrouvera du vendredi 27 au dimanche 29 octobre. Des passionné·e·s des technologies, des éducateur·rice·s et des makers se réuniront pour explorer le futur du Web ouvert.

Le MozFest, c’est plus de 1 600 visiteur·se·s, des participant·e·s de plus de 50 pays et 325 ateliers et conférences.

Vous avez jusqu’au 1er août pour répondre à l’appel à propositions avec des activités interactives et inclusives.

Il s’agit d’une formidable opportunité. Et, pour vous en convaincre, qui de mieux placé que le directeur général de la Mozilla Foundation, Mark Surman ?

Lire la suite

mercredi, 8 mars 2017

Une introduction cartoonesque à WebAssembly

Courbe décrivant la progression des performances pour JavaScript

Cet article est le premier d’une série de traductions d’articles écrits par Lin Clark et publiés sur le blog Hacks. La version anglaise est disponible ici. Merci à Adam, dattaz, Jeremie et à goofy et Benjamin pour la relecture :)


Lire la suite

Un petit cours accéléré de compilation à la volée (JIT)

Communiquer avec un alien ?

Cet article est le deuxième d’une série de traductions d’articles écrits par Lin Clark et publiés sur le blog Hacks. La version anglaise est disponible ici. Merci à dattaz, Jeremie et à goofy et Benjamin pour la relecture :) Si vous n’avez pas lu les autres articles, nous vous conseillons de démarrer depuis le début.


Lire la suite

Un petit cours accéléré d'assembleur

Discuter avec un alien

Cet article est le troisième d’une série de traductions d’articles écrits par Lin Clark et publiés sur le blog Hacks. La version anglaise est disponible ici. Merci à Jeremie et à goofy et Benjamin pour la relecture :) Si vous n’avez pas lu les autres articles, nous vous conseillons de démarrer depuis le début.


Lire la suite

Créer et manipuler des modules WebAssembly

L'utilisation de la représentation intermédiaire avec les différents composants

Cet article est le quatrième d’une série de traductions d’articles écrits par Lin Clark et publiés sur le blog Hacks. La version anglaise est disponible ici. Merci à dattaz, Jeremie et à goofy et Benjamin pour la relecture :) Si vous n’avez pas lu les autres articles, nous vous conseillons de démarrer depuis le début.


Lire la suite

D'où vient la rapidité de WebAssembly ?

Les différentes tâches à réaliser pour lancer une application JavaScript

Cet article est le cinquième d’une série de traductions d’articles écrits par Lin Clark et publiés sur le blog Hacks. La version anglaise est disponible ici. Merci à goofy et Benjamin pour la relecture :) Si vous n’avez pas lu les autres articles, nous vous conseillons de démarrer depuis le début.


Lire la suite

WebAssembly aujourd'hui et demain

Les différents navigateurs sont d'accord pour WASM

Cet article est le sixième d’une série de traductions d’articles écrits par Lin Clark et publiés sur le blog Hacks. La version anglaise est disponible ici. Merci à dattaz et à goofy et Benjamin pour la relecture :) Si vous n’avez pas encore lu les autres articles, nous vous recommandons de commencer depuis le début.


Lire la suite

mardi, 31 janvier 2017

Les sections HTML, CSS et JavaScript de MDN sont disponibles en français

Logo de MDN

TL;DR : Les 1 749 pages de MDN pour les sections HTML/JS/CSS sont désormais disponibles, à jour, en français.

Lire la suite

samedi, 14 janvier 2017

Dans les entrailles de Git

L'arbre pour le commit a1

Le billet qui suit a d’abord été publié sur son blog par Nicolas Leuillet, à qui nous devons l’excellent Wallabag. Cette traduction collaborative à laquelle a participé le groupe Framalang nous a semblé intéressante pour notre blog « technique » et c’est l’occasion pour nous de lancer une invitation à tous ceux qui voudraient publier ici sur les technologies web. N’hésitez pas à nous contacter.

 

Lire la suite

samedi, 29 octobre 2016

Le projet Quantum de Mozilla, des ambitions et des précisions

Capture_du_2016-10-28_23-43-53.png

Après un premier billet qui traçait les grandes lignes du projet et sa philosophie (Un saut quantique pour le Web) nous disposons maintenant d’un peu plus de précisions techniques grâce à cet article de Bill Mc Closkey que nous vous traduisons ci-dessous : après avoir mentionné les quatre projets distincts mais associés sous la bannière de Quantum, Bill nous expose l’avancement du projet Quantum Code et invite déjà à contribuer. Bill travaille notamment sur les processus séparés chez Mozilla, il n’est donc guère surprenant de le retrouver ici impliqué sur le projet Quantum.

Traduction MozFr : Julien / Sphinx, Jérémie et Goofy

Lire la suite

jeudi, 27 octobre 2016

Un saut quantique pour le Web

davidBryant.jpeg

Cet article est la traduction du billet A Quantum Leap for the Web écrit par David Bryant. David est à la tête de l’équipe Platform Engineering de Mozilla et il annonce ici le lancement et le futur proche du projet Quantum, qui vise à renouveler entièrement plusieurs composants majeurs sur lesquels reposent les technologies web actuelles.

Traduction MozFr : Sphinx, TheGennok et Goofy.

Lire la suite

dimanche, 18 septembre 2016

Les onglets contextuels dans Firefox Nightly

icône menu hamburger

Attention : cette fonctionnalité est encore expérimentale et peut être amenée à évoluer :) Pourquoi faire ? « Mais dis-moi plutôt qui tu es ? », Rafiki, Le Roi Lion Lorsque nous naviguons sur le Web, nous utilisons différents sites pour différents besoins. Notre identité numérique se compose parfois  […]

Lire la suite

- page 1 de 4