Certificats eMudhra : pourquoi la confiance du Web se retire

Un site peut présenter un certificat encore dans sa période de validité et voir pourtant sa connexion refusée. L’incident touchant des autorités intermédiaires d’eMudhra remet cette réalité au premier plan : la confiance accordée à un certificat dépend de toute une chaîne, et cette confiance peut être retirée lorsqu’un maillon devient dangereux. Le contrôle doit porter sur les logiciels effectivement déployés, ainsi que sur leurs mécanismes de mise à jour.

L’alerte reste d’actualité mercredi 28 octobre, alors que les éditeurs poursuivent la diffusion de leurs mesures de protection. Google avait annoncé un retrait de la racine emSign ECC Root CA – G3 prévu le 27 octobre dans Chrome. Ce calendrier annoncé ne signifie pas que chaque appareil et chaque application ont déjà reçu exactement la même configuration.

Ce qui s’est passé dans la chaîne eMudhra

Dans son billet du 20 octobre, Google décrit la compromission de clés privées associées à des certificats d’autorités intermédiaires. Le problème concerne la faiblesse des clés, pas simplement une erreur d’affichage du navigateur. Ces clés pouvaient permettre de signer des certificats trompeurs.

Google indique avoir engagé le blocage des clés concernées dans Chrome dès le 17 octobre et distribué une protection Android via Google Play Services le 19. Le retrait annoncé de la racine constitue une étape supplémentaire. Les responsables de services utilisant une chaîne rattachée à cette racine doivent donc examiner leur situation, même lorsque leur propre certificat n’a pas été émis de façon frauduleuse.

Le risque et la preuve d’une attaque doivent rester distingués. Une possibilité technique d’usurpation n’établit pas que tous les sites utilisant cet écosystème ont été attaqués, ni que toutes les connexions des internautes ont été interceptées. L’incident justifie des corrections ; il ne permet pas de reconstituer des intrusions sans éléments spécifiques.

Racine, intermédiaire, certificat du site : trois rôles

La documentation de Firefox sur les certificats décrit une hiérarchie. À son sommet, une racine est acceptée comme point d’ancrage par le logiciel. Elle permet de reconnaître des autorités intermédiaires, lesquelles délivrent les certificats présentés par les sites.

Le navigateur vérifie ainsi un chemin de signatures au lieu de connaître personnellement chaque site du Web. Le certificat du site relie notamment une clé publique au nom de domaine concerné. La clé privée correspondante doit rester secrète chez son détenteur. Les rôles sont liés, mais ils ne se confondent pas.

Une comparaison aide à visualiser cette organisation : un service local peut délivrer des documents parce qu’une autorité supérieure l’y autorise. La validité du document dépend alors aussi de la délégation. Cette image n’est pas un modèle cryptographique complet ; elle montre pourquoi un problème situé en amont peut affecter beaucoup plus qu’un seul site.

Une clé privée faible change l’ampleur du risque

La clé publique est destinée à être connue. La clé privée doit, elle, rester hors de portée des tiers. La sécurité repose notamment sur l’impossibilité pratique de reconstituer la seconde à partir de la première dans des conditions normales de génération et d’utilisation.

Le bulletin italien relayé et actualisé le 28 octobre par le CSIRT Toscana explique que la faiblesse des clés en cause permettait leur récupération à partir d’informations publiques. Une personne disposant de telles clés pouvait tenter d’émettre des certificats frauduleux acceptables pour des logiciels continuant à faire confiance aux chaînes concernées.

Le problème dépasse donc le simple remplacement d’un fichier sur un serveur. Il faut aussi que les logiciels clients cessent d’accepter les clés ou les chaînes devenues dangereuses. L’un agit sur ce que le site présente ; l’autre sur ce que l’appareil du visiteur est prêt à reconnaître.

Le chiffrement protège une connexion, pas la vérité d’un contenu

La documentation TLS de MDN distingue trois propriétés : confidentialité des échanges en transit, intégrité et authentification. Sur le Web, HTTPS utilise TLS pour établir une communication protégée entre le navigateur et le serveur.

La présence de HTTPS ne certifie donc pas qu’un article est exact, qu’un marchand livrera sa commande ou qu’une offre financière est honnête. Elle concerne la connexion au domaine identifié. Un site trompeur peut lui aussi disposer d’un certificat correctement délivré pour son propre nom.

Cette séparation est utile face à une alerte. Une erreur de certificat appelle une vérification de la connexion et de la chaîne de confiance. Une information douteuse appelle une vérification éditoriale de ses sources. Les deux problèmes peuvent coexister, mais la résolution de l’un ne résout pas automatiquement l’autre.

Pourquoi les appareils ne réagissent pas tous ensemble

Un navigateur, un système d’exploitation et une application peuvent utiliser des mécanismes de confiance différents. Le CSIRT souligne notamment le cas des logiciels disposant de leurs propres magasins de certificats. Mettre à jour le navigateur principal ne prouve donc pas que tous les outils d’un ordinateur ou d’une organisation ont reçu la même protection.

Mozilla a décrit sa propre réponse dans un billet de sécurité : blocage par OneCRL dès le 17 octobre pour les configurations standards, puis versions intégrant la protection pour les utilisateurs qui ne reçoivent pas normalement ces mises à jour distantes. Une correction complémentaire a aussi été publiée pour Android le 21 octobre.

Cette diversité explique qu’une page puisse fonctionner dans une application et échouer dans une autre. Elle ne permet pas de désigner automatiquement le logiciel le plus permissif comme celui qui a raison. La différence doit être examinée à partir des chaînes présentées, des versions et des politiques effectivement appliquées.

Révocation et retrait de racine ne sont pas identiques

Une révocation ou une liste de blocage peut viser des certificats déterminés. Le retrait d’une racine modifie plus largement les chemins de confiance acceptés par un logiciel. C’est pourquoi des certificats légitimes peuvent nécessiter une migration alors que leurs détenteurs n’ont commis aucune fraude.

La politique du magasin de racines de Mozilla prévoit l’inclusion, la désactivation et le retrait de certificats. Elle fixe également des exigences aux autorités et à leurs intermédiaires. La confiance du navigateur est ainsi une décision maintenue dans le temps, accompagnée de règles et de contrôles, plutôt qu’une garantie acquise une fois pour toutes.

Pour un administrateur, remplacer uniquement le certificat visible sans examiner les intermédiaires peut laisser le problème entier. Il faut vérifier la chaîne complète et le résultat depuis les environnements réellement utilisés par les visiteurs, puis suivre les indications de l’hébergeur et de l’autorité de certification.

Les gestes utiles pour les lecteurs et les sites

Pour les internautes, les recommandations des éditeurs et du CSIRT convergent : installer les mises à jour disponibles et prendre au sérieux les messages signalant un certificat non fiable. Forcer l’accès pour faire disparaître l’obstacle enlève précisément la protection déclenchée au moment où la chaîne ne peut plus être acceptée.

Pour une organisation, le travail commence par un inventaire : sites publics, applications, outils internes et environnements embarquant leurs propres magasins. Le bulletin de NHS England invite notamment à examiner ces dépendances et à surveiller les anomalies de certificats. Les corrections doivent ensuite être appliquées selon les instructions propres aux produits utilisés.

L’incident illustre une propriété fondamentale du Web : une connexion sûre repose à la fois sur la cryptographie et sur une confiance organisée entre plusieurs acteurs. Notre rubrique Tech et sciences suit les évolutions de cet écosystème, tandis que les décryptages en expliquent les mécanismes.