Depuis peu, certaines connexions sécurisées à des sites peuvent être refusées par Firefox. Il s’agit d’une mesure voulue par Mozilla, qui a expliqué dans un récent billet la raison de ce refus : lutter contre certaines clés de chiffrement trop faibles. Dans le même temps, Mozilla en dit un peu plus sur son projet Mortar.

Environ 7 000 des 140 000 sites les plus visités sont, selon ComputerWorld, concernés par ce blocage des connexions sécurisées. L’explication tient dans un billet assez court publié par l’ingénieur David Keeler, de Mozilla, il y a quelques jours : certaines clés utilisées pour la négociation TLS sont tout simplement trop courtes.

Une conséquence directe de la faille Logjam

La mesure concerne plus spécifiquement l'échange de clés Diffie-Hellman lors de la négociation initiale afin d'établir une connexion sécurisée. Ce protocole octroie certains bénéfices, notamment la confidentialité persistante qui empêche un pirate de récupérer des données en cas de fuite de la clé privée. Mais cette technique a aussi son lot de problèmes dans certains cas.

Le plus important est une conséquence de la faille Logjam, que nous avions analysée en mai 2015. Pour rappel, un pirate l’exploitant pouvait provoquer la rétrogradation de la sécurité d’un serveur en le forçant à se servir de clés de 512 bits. Une protection trop faible pour résister efficacement aux attaques. La faille avait été corrigée, mais il était recommandé à tous les acteurs impliqués de passer si possible à des clés de 1 024 bits au moins, et même de 2 048 bits si possible.

Point de salut en-dessous de 1 024 bits

Plus d’un an après, Mozilla juge que les utilisateurs ne peuvent plus attendre. Des sites utilisent encore des clés trop faibles. Firefox ne doit donc plus prendre le risque selon l’éditeur : toute connexion « sécurisée » exploitant le protocole Diffie-Hellman avec des clés de 1 023 bits ou moins sera toute simplement refusée. Côté utilisateur, le symptôme est une erreur spécifique : « ssl_error_weak_server_ephemeral_dh_key », « dh » signifiant ici Diffie-Hellman.

Signalons que Firefox est le premier à agir en ce sens, mais que d'autres navigateurs pourraient suivre rapidement. En mai de l'année dernière, Google avait en effet annoncé que « les serveurs qui utilisent actuellement DHE [Diffie-Hellman Exchange] devraient se mettre à jour et passer à Elliptic curve Diffie–Hellman. Si cela est impossible, utilisez au moins DHE avec des groupes de 1024 bits et ne soyez pas trop surpris si Chrome commence à utiliser du chiffrement RSA avec votre site dans le futur ».

Notez que sur les mêmes 140 000 sites les plus visités, 67 % possèdent des clés 2 048 bits. Cependant, il suffit parfois d’un seul site pour déclencher une fuite de données importante. Les deux dernières années ont prouvé à bien des reprises qu’une sécurité laxiste pouvait avoir de fortes répercussions sur les données des utilisateurs. La récente confirmation des 500 millions de comptes Yahoo piratés tient lieu de rappel.

Mozilla veut intégrer PDFium et l’API Pepper dans Firefox

Parallèlement, les ingénieurs de Mozilla travaillent sur la poursuite du projet Mortar. Derrière ce nom se cache une volonté simple : réduire autant que possible le coût d’entretien de Firefox afin que les ressources soient consacrées à d’autres activités.

Dans le cadre de Mortar, l’éditeur réfléchit donc à intégrer deux projets déjà existants : PDFium et l’API Pepper. Le premier est conçu par Google et est tout simplement un lecteur PDF. Firefox en possède bien un, mais puisque le projet de Google est open source, il peut être intégré dans Firefox en tant que tel. Quant à l’API Pepper, elle permettrait à Firefox de se débarrasser enfin de l’ancienne version NPAPI du plugin Flash en adoptant une architecture plus moderne.

Dans un cas comme dans l’autre, le résultat n’est pas garanti. Comme indiqué par Mozilla, les ingénieurs ont actuellement des prototypes fonctionnels de Firefox avec PDFium et Pepper, mais du travail reste à accomplir. L’idée serait de proposer ces deux ajouts – si tout se passe bien – durant le premier semestre 2017. Dans le cas de PDFium, le lot de fonctionnalités contiendrait la lecture, la sauvegarde locale des documents, l’impression et la possibilité de remplir les formulaires PDF. D’ici la fin de l’année en cours, toutes les opérations de base devraient être gérées (chercher, zoom, rotation, etc.).