Huit certificats eMudhra emSign intermédiaires engagés; les navigateurs les bloquent

Le 20 octobre, les principaux programmes de racines de navigateur ont confirmé que les clés privées associées à huit certificats intermédiaires émis par eMudhra (marque emSign) étaient compromises. Un certificat intermédiaire peut délivrer, par délégation de la racine, des certificats valables pour n'importe quel domaine; quiconque possède sa clé privée pourrait créer des certificats que les navigateurs accepteraient comme légitimes. Les signatures publiques et le calendrier de l'avis permettent de reconstruire ce qui s'est passé et les impacts concrets qu'on peut attendre, mais il n'y a aucune question sur l'origine et l'étendue de l'évasion.

Faits confirmés: un chercheur a signalé la détection l'après-midi du 17 Octobre (UTC), et Chrome a mis en œuvre un bloc technique des clés ce même jour entre 18: 05 et 19: 45 UTC; Firefox a reçu la notification à 20: 06 UTC et a distribué son verrou (OneCRL) aux installations standard à 22: 59 UTC. Les huit intermédiaires concernés sont: EM DV TLS CA - G3B; EM DV TLS CA - G3C; EM OV TLS CA - G3B; EM OV TLS CA - G3C; EM EV TLS CA - G3B; EM EV TLS CA - G3C; EM OV CS CA - G3B; et EM OV CS CA - G3C. Il a également été confirmé que chaque certificat a une copie signée par Sectigo sous sa racine AAA Certificat Services, et que eMudhra a révoqué les huit certificats après notification. Un ingénieur de Mozilla, Dennis Jackson, a publié la liste des certificats et timbres qui ont démontré la signature avec les clés compromises.

Techniquement, le risque spécifique dépendait de la question de savoir s'il y avait déjà des certificats délivrés par ces intermédiaires et si ces certificats avaient été enregistrés dans la transparence des certificats (CT). Chrome a trouvé qu'il n'y avait aucune entrée CT connectée aux six intermédiaires utilisés pour TLS avant le verrou, donc, selon votre vérification, aucun navigateur qui nécessite CT n'aurait dû compter par défaut sur de nouveaux certificats signés par ces clés. Cependant, l'existence d'exemplaires signés et la présence des racines dans différents entrepôts compliquent l'image.

Quels programmes et utilisateurs ont été touchés: les navigateurs qui mettent en œuvre des mécanismes de révocation centralisés (Chrome avec CRLSet, Firefox avec OneCRL et Apple sur leurs listes) ont reçu le verrou rapidement et ont cessé de faire confiance aux intermédiaires; Microsoft et d'autres fournisseurs ont également bloqué les certificats. Cependant, de nombreuses applications et bibliothèques qui valident TLS en dehors de ces navigateurs ne consultent pas efficacement ou n'appliquent pas la révocation. Exemples pertinents: Go binaires, environnements utilisant la collection de certification de Python, et beaucoup de distributions Linux qui dépendent des magasins de certificats locaux peuvent continuer à valider les chaînes tant que le logiciel n'est pas mis à jour ou que le paquet ne change pas.

Mesures techniques déjà prises et leurs effets: Google a implémenté un filtre dans la librairie standard Go qui détecte et rejette toute chaîne contenant les clés compromises; que la correction nécessite de remodeler les programmes avec la version go parcheada. D'autres projets (certifi, webpki-roots, Homebrew) ont choisi de supprimer la racine emSign ECC Root CA - G3 de leurs paquets, une mesure efficace pour réduire la confiance, mais qui rompt également la validation pour tout serveur légitime qui dépend encore de cette racine. Mozilla et NSS ont appliqué la même exclusion, et ont averti que certains serveurs ne seront plus accessibles aux clients qui utilisent ces répertoires jusqu'à ce que ces serveurs migrent vers des certificats enchaînés vers d'autres racines.

Informations encore incertaines: il n'a pas été publié comment ou quand exactement les clés eMudhra sont sorties, ou si la divulgation était externe ou interne; il n'y a pas de preuve publique d'abus antérieur sauf la signature utilisée par l'enquêteur pour prouver la possession (le message signé avec chaque clé). Mozilla indique qu'elle travaille avec l'AC dans une enquête médico-légale, mais les détails du vecteur de fuite n'ont pas été divulgués.

Conséquences pratiques À court terme, les navigateurs modernes recevant un verrou centralisé protègent la plupart des utilisateurs contre les faux certificats délivrés avec ces clés. Cependant, les systèmes qui n'appliquent pas la révocation ou n'utilisent pas des entrepôts mis à jour resteront exposés et la stratégie d'élimination de la racine des faisceaux populaires peut produire une indisponibilité temporaire des services légitimes jusqu'à ce que ses opérateurs remplacent les certificats. À moyen terme, la confiance dans eMudhra / emSign sera affectée et les programmes dépendant de leurs racines devront évaluer la nécessité de la rotation des certificats et audits supplémentaires.

Recommandations spécifiques - confirmées et réalisables - selon le type de lecteur : pour les administrateurs de serveurs TLS, vérifiez d'abord si votre certificat actuel se connecte à emSign Root TLS CA - G3 ou emSign ECC Root CA - G3 ; si oui, obtenez et déployez un nouveau certificat qui canalisera vers une racine différente et valide dès que possible, et confirmez que vos nouveaux certificats sont enregistrés dans Certificat Transparency. Les outils et les recherches publics de CT aident à détecter les émissions inattendues : voir la base de données sur la transparence des certificats à l'adresse suivante : https: / / www.certificat-transparency.org / et les vues de Google dans https: / / transparencereport.google.com / https / certificats / aperçu.

Pour les opérateurs de logiciels et les développeurs: mettre à jour les bibliothèques et les binaires touchés. Si vous utilisez Go, reconstruisez vos projets avec la version Go contenant le verrou de clé; Go publie des informations de sécurité et des versions dans https: / / go.dev / sécurité. Si votre logiciel intègre des faisceaux externes (certifi, webpki-roots, ca-certificats Homebrew, NSS), mettez-les à jour et testez l'impact sur les environnements de mise en scène avant de se déployer dans la production, parce que certains faisceaux ont choisi d'enlever la racine complète et qui peuvent briser les connexions.

Pour les gestionnaires de sécurité et les fiduciaires: vérifiez que vos clients et agents font confiance à la révocation et dans les paramètres distants / mises à jour automatiques des listes de verrouillage; si votre environnement empêche Firefox ou Chrome de recevoir OneCRL / CRLSet, implémenter des contrôles supplémentaires (liste de verrouillage de clé publique, inspection TLS) ou envisager d'éliminer temporairement la confiance dans emSign racines jusqu'à ce qu'il y ait la certitude qu'il n'y a pas d'émissions frauduleuses.

Pour les utilisateurs finaux : tenir à jour les navigateurs et les systèmes. Les navigateurs susmentionnés ont reçu et appliqué des blocages qui protègent la plupart des utilisateurs sans intervention manuelle; si un site cesse de charger après les mises à jour, il est probable que votre opérateur de serveur devra renouveler le certificat.

Ce qu'il faut surveiller maintenant : des recherches continues de CT pour détecter les certificats délivrés par les clés compromises, l'enregistrement et la vérification de l'utilisation des interfaces d'émission par l'AC, et les rejets officiels de programmes eMudhra et root. Les causes profondes demeurent une question en suspens et justifient que les organisations examinent leurs unités de fiducie tierces et leurs politiques de révocation afin de réduire l'incidence de défaillances semblables à l'avenir.

Résumé: les clés de huit intermédiaires eMudhra ont été rapidement compromises et bloquées par les grands programmes racine ; les navigateurs modernes appliquent déjà des mesures d'atténuation, mais de nombreuses applications en dehors de ces clients restent vulnérables jusqu'à ce qu'elles soient mises à jour ou reconstruites. Il est essentiel que les administrateurs renouvellent les certificats enchaînés aux racines touchées, que les développeurs récompensent avec les versions des librairies parched et que les équipes de sécurité vérifient l'acceptation de la révocation dans leur environnement.