if ( !emtpy($headline_subheadline ) ) : ?>
Les experts en sécurité exhortent les organisations à examiner les dépendances des certificats au-delà des navigateurs à mesure que les modifications du magasin de confiance entrent en vigueur.
endif; ?>
La société indienne de confiance numérique eMudhra a annoncé qu’elle se retirait du secteur mondial des certificats SSL/TLS et propose à ses clients des certificats émis par Sectigo comme alternative, suite à la compromission des clés privées derrière huit de ses autorités de certification intermédiaires.
Le conseil d’administration de la société a décidé « de se retirer volontairement du secteur mondial des certificats SSL/TLS », a déclaré eMudhra dans un communiqué de presse. L’entreprise ajoute que la souveraineté des données et les exigences de conformité ont accru la complexité et les coûts de l’entreprise.
« Le niveau d’amplification des médias sociaux autour de cet incident a suscité une surveillance disproportionnée par rapport à la place de SSL/TLS dans notre activité », a déclaré le président d’eMudhra, V Srinivasan, dans le communiqué.
La société a déclaré qu’elle contacterait les clients concernés pour remplacer gratuitement les certificats. Il a également déclaré qu’il maintiendrait les services de révocation et d’état des certificats en fonctionnement jusqu’à ce que chaque certificat émis ait expiré ou soit remplacé.
Sectigo proposé comme alternative
Dans la mise à jour client, eMudhra a déclaré qu’elle mettait les certificats émis par Sectigo à la disposition de tous ses clients.
« Nos certificats racine G1 restent actifs et continuent d’être entièrement pris en charge », a indiqué la société dans la mise à jour. La version du 22 octobre indique que les racines du G1 RSA « continueront à servir les clients jusqu’à ce que cette transition soit terminée ».
eMudhra a déclaré qu’elle fournirait gratuitement des certificats de remplacement par l’intermédiaire de ses partenaires et continuerait à exploiter les services de révocation et de statut des certificats jusqu’à ce que tous les certificats émis aient expiré ou soient remplacés. Les utilisateurs de CertiNext peuvent demander des certificats Sectigo via leurs comptes ; les autres clients peuvent contacter le support eMudhra, ajoute le communiqué.
Niyati Daftary, analyste principal chez Gartner, a déclaré que les organisations devraient considérer les racines du G1 « comme un pont possible, et non automatiquement comme la destination finale ».
« Alors que l’entreprise abandonne SSL/TLS mondial et que ses racines restantes sont toujours soumises à l’examen minutieux des navigateurs, la prudence consiste à déplacer les services critiques vers une autorité de certification indépendante et entièrement fiable chaque fois que le délai le permet », a déclaré Daftary.
Si G1 est utilisé pour éviter une panne immédiate, elle recommande de fixer un délai ferme et de documenter un plan de migration ultérieur.
Elle a recommandé d’inclure les autorités émettrices, les certificats intermédiaires et racines, les accords de signature croisée, l’infrastructure de révocation et le statut de confiance du navigateur dans les évaluations des risques par des tiers.
Yash Kadakia, co-fondateur et directeur technique de Security Brigade, a déclaré que le passage à une autre racine exploitée par la même société ne résout pas nécessairement les problèmes de confiance et de gouvernance.
« La dernière chose dont les organisations ont besoin, c’est de migrer deux fois », a déclaré Kadakia.
Sectigo n’a pas immédiatement répondu à une demande de commentaire.
Java et d’autres systèmes peuvent nécessiter des correctifs distincts
Selon Sakshi Grover, directeur de recherche chez IDC, le remplacement du certificat d’un site Web ne résoudra peut-être pas toutes les dépendances d’un environnement d’entreprise. Elle a déclaré que l’exposition résiduelle réside dans les systèmes qui maintiennent leurs propres magasins de confiance et ne se mettent pas à jour selon le même calendrier que les navigateurs. Ceux-ci incluent les magasins de clés Java, les environnements d’exécution de langage, les images de conteneurs, les configurations TLS mutuelles, les proxys, les équilibreurs de charge, les appareils VPN et de sécurité et les appareils intégrés.
« Le constat le plus difficile pour de nombreuses organisations sera qu’elles ne peuvent pas du tout répondre à ces questions », a déclaré Grover, faisant référence aux endroits où les décisions de confiance en matière de certificats sont prises en dehors des navigateurs et des systèmes d’exploitation.
Grover a noté que Google a signalé n’avoir trouvé aucun certificat lié aux intermédiaires concernés dans les journaux de transparence des certificats avant qu’ils ne soient bloqués. Elle a déclaré que c’était rassurant pour les clients qui appliquent la transparence des certificats, mais ce n’est pas le cas de certaines applications et appareils autres que les navigateurs. L’exploitation nécessiterait également qu’un attaquant soit positionné pour intercepter le trafic, a-t-elle déclaré, décrivant le risque restant comme limité et ciblé plutôt que large.
Azul, un fournisseur Java, a déclaré dans un communiqué que Java ne vérifie pas la révocation des certificats par défaut. Un kit de développement Java (JDK) non corrigé pourrait donc continuer à accepter un faux certificat signé avec une clé intermédiaire compromise si la chaîne concernée reste fiable.
Azul a déclaré avoir publié des versions Azul Zulu mises à jour d’OpenJDK et d’Azul Prime. Les mises à jour ajoutent les huit certificats concernés à la liste des certificats bloqués du JDK, a indiqué la société.
Grover a recommandé que les équipes de sécurité identifient d’abord où les décisions de confiance se produisent en dehors des navigateurs et des systèmes d’exploitation, en donnant la priorité aux systèmes qui acceptent les connexions de parties externes et de points de terminaison TLS mutuels. Les équipes doivent ensuite déterminer quels systèmes peuvent être mis à jour pour se méfier d’un certificat intermédiaire spécifique ou d’une clé publique, a-t-elle déclaré.
Date limite Chrome pour les titulaires de certificat
Mozilla a supprimé emSign ECC Root CA – G3, la racine qui a signé les huit intermédiaires compromis, de son magasin de confiance. Google a déclaré dans un article de blog que la suppression de la racine du Chrome Root Store devrait atteindre tous les appareils le matin du 27 octobre, heure du Pacifique.
« Pour éviter toute casse, les opérateurs de sites Web dont les certificats sont liés à emSign ECC Root CA – G3 doivent immédiatement acquérir et installer un nouveau certificat TLS », a déclaré Google dans le message.
Daftary a déclaré que les entreprises connaissent souvent leur revendeur de certificats, mais pas la hiérarchie des autorités de certification qui sous-tend leur confiance.
« Cela crée un risque de tiers non reconnu, capable d’affecter des milliers de services à la fois », a-t-elle déclaré. Elle a ajouté que les RSSI devraient inclure les autorités de certification émettrices, les racines, les accords de signature croisée et l’infrastructure de révocation dans leurs évaluations des cyber-risques tiers. « Vous pouvez sous-traiter un service, mais vous ne pouvez pas sous-traiter la responsabilité », a déclaré Kadakia.
