Dans un billet de blog, la fondation s'excuse de ce qui s'est passé, certains utilisateurs attendant encore un correctif, notamment ceux qui ont une ancienne version du navigateur.
Le système mis en place pour la protection des extensions va être revu afin d'éviter que la situation ne se reproduise. L'expiration du certificat a en effet éclairé le contrôle de Mozilla sur ces éléments, ce qui peut être un problème.
Dans un second billet plus technique, Eric Rescorla revient sur la mécanique actuellement utilisée pour la signature numérique des extensions et leur diffusion.
Notamment sur la manière dont est généré le certificat intermédiaire, à travers un HSM stocké hors-ligne, auquel l'équipe n'accède que lorsque c'est nécessaire. Il explique également comment les développeurs ont répondu rapidement au problème.
Ainsi, la signature de nouvelles extensions a été stoppée, un premier correctif évitant de demander la validation des extensions pour les utiliser. Tout a été remis en place depuis, un nouveau certificat intermédiaire ayant été généré et diffusé.
Un post-mortem sera publié la semaine prochaine pour évoquer certains points plus en détails, comment les décisions qui vont être prises pour faire évoluer la mécanique de signature des extensions, de mise à jour d'urgence et la liste de toutes les éventuelles « time bomb », dont l'expiration de certificats.
Commentaires (14)
#1
Donc aucun changement significatif de prévu.
#2
Moi ce qui me gonfle dans cette histoire, c’est de me retrouver sans mes extensions, sans que j’ai mon mot à dire. Un message informatif en laissant le choix à l’utilisateur de les désactiver ou non aurait été mieux, que le je pense à votre place, on sait ce qui est bon pour vous.
Il y a un endoit où on peut remonter ses doléances chez mozilla ?
#3
Oui, ce qui est con, c’est que le navigateur fonctionne sans mémoire et décide du jour au lendemain que les extensions sont devenues invalides.
Qu’il bloque les nouvelles extensions, OK mais pas celles qui étaient valides la veille alors que c’est le certificat qui est devenu invalide.
#4
Le problème des certificats est le même depuis des années. Un autorité qui signe les certificats en dessous… Quand on change son certificat sur son serveur, le client fait confiance à l’autorité plus qu’au service.
On devrait toujours avoir DEUX certificats ayant des dates de fin décalées afin de faire un recouvrement. Le nouveau certificat devrait être signé aussi par l’ancien (même la clef RSA augmente de valeur entre temps). Ainsi, le client (navigateur, client ssh…) voit le nouveau certificat, voir l’ancien et fait la transition en douceur EN PLUS de l’autorité qui est au dessus.
En plus, on gère ainsi les transitions de certificat (il faut bien en changer un jour) dans le protocole ce qui n’est pas le cas aujourd’hui !
#5
Et si le certificat a été révoqué parce qu’il a été compromis (et donc tes extensions) d’une manière ou d’une autre ?
#6
Il n’y a pas eu de révocation dans ce cas ci, juste une expiration du certificat. En cas de révocation, bloquer est acceptable.
#7
En attendant, les versions antérieures à la 66 (ou la 60, je ne sais plus) sont toujours touchées par le problème. Et Mozilla n’a pas l’air de se presser pour les réparer.
#8
En fait, ce qu’il faudrait, c’est faire à la manière de la signature des exécutables : du timestamping.
En gros, quand tu signes ton binaire avec ton certificat, tu ajoutes un timestamp (date/heure). Ton binaire sera alors considéré valable du moment que ton certificat est valable, à l’heure du timestamp.
Evidemment, si le certificat est révoqué, cela ne marche plus (mais c’est le but).
J’espère vraiment qu’ils vont se pencher sur cette approche. Je vais suivre le post-mortem avec intérêt.
#9
Je ne suis pas sûr qu’il soit toujours possible de faire la différence. Un certificat révoqué et un certificat expiré sont tous les deux non valides…
#10
la date d’expiration est dans le certificat. C’est donc simple à tester. Et si nécessaire, il faut faire comme Indigo74 l’indique au dessus.
#11
(et pour fred42 aussi)
Pour plus d’infos :https://en.wikipedia.org/wiki/Code_signing#Time-stamping
#12
Si c’est pas une version supportée, c’est normal, et ce n’est pas à Mozilla de faire quoi que ce soit… normal de ne pas avoir de mise à jour sur une version qui n’est plus mise à jour.
#13
Oui, on en revient à de l’obsolescence programmée pour des raisons de sécurité
" />
EDIT: Si tu ne l’as pas encore fait, tu peux lui ajouter le nouveau certificat à la main.
#14
Je l’avais déjà fait. Mais merci de l’info.
Le lien pour faire ça au cas où ça intéresserait d’autres personnes :
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/