L'héritage Comodo de Sectigo: quand l'émission déléguée fragilise la confiance certificate

Résumé

• Registre public confirmé:Le rapport d'incident de Comodo indique que le 15 mars 2011, un compte d'autorité d'enregistrement a été piraté et utilisé pour émettre neuf certificats frauduleux sur sept domaines; il précise aussi que tous ont été révoqués immédiatement après leur découverte et que la surveillance du trafic du répondeur OCSP n'a pas détecté de tentative d'utilisation après la révocation. (Rapport d'incident Comodo)
• Réponse des navigateurs et des plateformes:Mozilla, Microsoft et d'autres opérateurs de navigateurs et de plateformes ont traité cet événement comme plus qu'une simple affaire interne à l'émetteur. Mozilla a déployé une mise à jour de la liste de révocation de certificats, Microsoft a publié l'avis de sécurité 2524375 ainsi qu'une mise à jour qui a placé les neuf certificats dans le magasin de certificats non approuvés de Windows, et le suivi de Mozilla a décrit le chemin de compromission de l'autorité d'enregistrement. (Avis Mozilla,Avis Microsoft,Suivi Mozilla)
• Périmètre de responsabilité:Les preuves publiques indiquent une défaillance de l'émission déléguée, et non une compromission publique des clés racine ou des modules de sécurité matériels de Comodo. Comodo a déclaré que son infrastructure d'AC et ses clés HSM n'avaient pas été compromises. Cette distinction réduit la portée de l'affirmation technique, mais elle ne réduit pas le problème de responsabilité: le compte délégué a tout de même produit des certificats de confiance pour des domaines à forte valeur.
• Évaluation:L'attaquant est responsable de l'intrusion et de la tentative d'utilisation abusive. Comodo contrôlait le modèle d'émission déléguée, l'authentification des revendeurs et les contrôles post-incident; les fournisseurs de navigateurs et de systèmes d'exploitation contrôlaient la défiance d'urgence; les programmes racine contrôlaient la confiance continue; les services des parties prenantes et les utilisateurs ont subi des conséquences qu'ils ne pouvaient pas observer directement.

Une autorité de certification peut faillir loin de la clé racine

Les incidents d'autorité de certification sont souvent imaginés comme une seule compromission cinématographique: un attaquant vole une clé privée racine, forge le web, et tout le système de confiance s'effondre. L'incident Comodo a été plus ordinaire et plus instructif. Comodo a déclaré que son infrastructure d'AC n'avait pas été compromise et que les clés de ses modules de sécurité matériels n'avaient pas été compromises. Les certificats frauduleux ont été émis via un compte d'autorité d'enregistrement, une porte d'entrée déléguée vers la plateforme de commande de certificats. (Rapport d'incident Comodo)

Cette différence est importante. Une compromission de clé racine poserait la question de savoir si l'ancre cryptographique fondamentale reste utilisable. Une compromission de l'émission déléguée pose une question opérationnelle plus difficile: quelle quantité de pouvoir pratique d'AC est placée dans les comptes partenaires, les flux de travail des revendeurs, le personnel de validation, les systèmes automatisés et les canaux de révocation d'urgence? Si un compte délégué peut entraîner l'émission de certificats pour mail.google.com,www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org et login.live.com, alors le système de confiance n'a pas échoué à la racine mathématique. Il a échoué à la périphérie administrative.

La périphérie administrative est là où vit l'internet public. Les utilisateurs ne décident pas quelle autorité d'enregistrement a validé une demande de certificat. Ils voient une icône de cadenas, un nom de domaine et l'acceptation de la chaîne par le navigateur. Les fournisseurs de navigateurs et les programmes racine ne font pas seulement confiance à un siège social unique; ils font confiance au système opérationnel qui entoure la clé privée.

Ce système comprend les procédures de validation, la sécurité des comptes, la supervision des revendeurs, les preuves d'audit, la capacité du service de révocation, le signalement des incidents et la volonté de retirer ou de restreindre la confiance lorsque des défaillances se reproduisent.

Le dossier Comodo est donc un cas utile de responsabilité parce que le nombre de certificats frauduleux était faible. Neuf certificats suffisent à montrer le mode de défaillance sans noyer la leçon dans des milliers de cas marginaux. L'incident n'a pas eu besoin de provoquer une campagne d'interception de masse connue pour exposer un problème de gouvernance. Il a montré qu'un compte délégué pouvait transformer le statut de racine de navigateur d'une autorité de certification en certificats pour certaines des destinations d'identité les plus sensibles d'internet.

Les noms eux-mêmes portent le problème. Un certificat pour un point de terminaison de connexion n'est pas un artefact décoratif. C'est un justificatif d'identité cryptographique présenté aux navigateurs. Si un attaquant peut combiner un tel certificat avec une redirection de trafic, une manipulation DNS, un contrôle du réseau local, une interférence de routage, un logiciel malveillant ou un accès réseau au niveau étatique, l'utilisateur peut n'avoir aucun moyen ordinaire de voir que la connexion n'est pas avec le service prévu. Microsoft a averti que les certificats pouvaient être utilisés pour usurper du contenu, effectuer des attaques de hameçonnage ou des attaques de l'homme du milieu contre les utilisateurs de navigateur. (Avis Microsoft 2524375)

Le constat correct est limité. Le dossier public ne montre pas que les neuf certificats ont été utilisés dans une interception à grande échelle réussie. Comodo a déclaré qu'un seul a été vu en direct sur internet et que la surveillance du trafic du répondeur OCSP n'a pas détecté de tentative d'utilisation après la révocation. Microsoft et Mozilla ont tout de même traité l'événement comme urgent parce que la confiance dans les certificats est préventive par nature. Un certificat qui peut usurper un domaine de connexion majeur est dangereux avant que les preuves post-incident ne prouvent une exploitation de masse.

La chronologie publique est inhabituellement concrète

Le rapport d'incident de Comodo fournit la première colonne vertébrale solide. Il indique que le 15 mars 2011, une autorité d'enregistrement a subi une attaque qui a entraîné la compromission d'un compte utilisateur de cette AR. Ce compte a ensuite été utilisé frauduleusement pour émettre neuf certificats pour sept domaines. Comodo a déclaré que tous les certificats ont été révoqués immédiatement après leur découverte. Ce même rapport a listé les domaines et les numéros de série et a distingué les certificats vus en direct de ceux qui ne l'ont pas été. (Rapport d'incident Comodo)

Le suivi de Mozilla a relié cette défaillance au niveau du compte à la confiance du navigateur. Mozilla a déclaré qu'un partenaire AR de Comodo avait subi une violation de sécurité interne, et que l'attaquant avait utilisé le compte de l'AR auprès de Comodo pour obtenir l'émission frauduleuse de neuf certificats. Mozilla a également noté que les certificats avaient été révoqués, que Firefox avait déployé des mises à jour pour les mettre sur liste noire, et que Mozilla discutait de mesures supplémentaires avec Comodo et d'autres AC. (Suivi Mozilla)

L'avis de sécurité 2011-11 de la fondation Mozilla est laconique mais important. Il annonce une mise à jour de la liste noire des certificats HTTPS le 22 mars 2011, avec un impact élevé, affectant Firefox et SeaMonkey, et décrit plusieurs certificats HTTPS invalides placés sur la liste noire pour empêcher toute utilisation abusive. L'enregistrement Bugzilla pour le travail de blocage est une piste publique pour la réponse côté navigateur. (MFSA 2011-11,Mozilla Bugzilla 642395)

L'avis de sécurité 2524375 de Microsoft a ajouté une couche plateforme. Microsoft a déclaré que Comodo l'avait informé le 16 mars 2011 que neuf certificats avaient été signés pour le compte d'un tiers sans validation suffisante de son identité. Microsoft a listé les propriétés affectées, décrit les risques d'usurpation, d'hameçonnage et d'homme du milieu, et a indiqué que Comodo avait révoqué les certificats et les avait inscrits sur sa liste de révocation. Microsoft a tout de même publié des mises à jour pour placer les neuf certificats dans le magasin de certificats non approuvés local, car les vérifications de révocation n'étaient pas assez robustes pour garantir une protection dans toutes les conditions réseau. (Avis Microsoft 2524375)

Ce dernier point est la charnière. Si la révocation seule était suffisamment fiable, une mise à jour du système d'exploitation serait moins urgente. L'avis de Microsoft explique clairement le problème: lorsque les points de terminaison CRL ou OCSP ne peuvent pas être atteints, les navigateurs et les applications peuvent continuer d'une manière qui expose les utilisateurs. Les certificats avaient été révoqués par l'émetteur, mais les logiciels des parties prenantes avaient encore besoin d'une logique de défiance locale pour éliminer l'incertitude.

C'est à ce moment qu'un incident d'AC devient un incident de navigateur, de système d'exploitation et d'écosystème.

Le détail ultérieur du 26 mars dans le rapport de Comodo est également révélateur. Comodo a déclaré avoir détecté et contrecarré une intrusion dans un compte utilisateur de revendeur le 26 mars, et que les nouveaux contrôles mis en place après l'incident du 15 mars ont éliminé tout risque d'émission frauduleuse de certificat. Il a également déclaré penser que l'attaque provenait du même auteur. Cette mise à jour n'est pas simplement une note secondaire. Elle suggère une nouvelle tentative contre l'émission déléguée après la première compromission, et place les contrôles post-incident sous examen. (Rapport d'incident Comodo)

Pour un registre public de responsabilité, la chronologie est solide mais incomplète. Elle indique au public la date, le chemin du compte délégué, le nombre de certificats, les domaines, l'affirmation de révocation, la réponse des navigateurs et systèmes d'exploitation, et l'existence d'une tentative ultérieure bloquée. Elle ne publie pas un rapport d'enquête indépendant complet, la méthode exacte d'accès initial, l'environnement de contrôle complet du revendeur, les conséquences d'audit, les communications privées avec les programmes racine, ni les seuils de décision exacts utilisés par les fournisseurs de navigateurs.

La délégation n'est pas une échappatoire à la responsabilité

La défense la plus tentante en matière d'émission déléguée est aussi la plus faible en matière de responsabilité: l'AC racine n'a pas été compromise, donc la défaillance se trouve ailleurs. Techniquement, cela peut être vrai. En matière de gouvernance, cela ne suffit pas. Une autorité de certification choisit de déléguer ou non les fonctions de validation et de commande, comment authentifier les partenaires, quels domaines nécessitent des vérifications supplémentaires, comment les anomalies d'émission sont détectées, et quels acteurs délégués reçoivent un accès pratique à l'émission de certificats de confiance par les navigateurs.

Cela ne signifie pas que tout modèle délégué est imprudent. L'émission de certificats à grande échelle a toujours dépendu de la distribution. Les entreprises, les hébergeurs, les revendeurs et les canaux de services gérés peuvent aider les organisations à obtenir rapidement des certificats. L'automatisation et la délégation peuvent réduire les coûts et améliorer l'adoption. La question de responsabilité est de savoir si le modèle de délégation comporte des contrôles proportionnés à ce que le compte délégué peut faire.

Les certificats Comodo n'étaient pas pour des domaines obscurs à faible valeur d'abus. Ils concernaient des domaines associés à la messagerie web, à la recherche, à la distribution de logiciels, aux extensions de navigateur et à la connexion. Un système d'émission déléguée utile devrait reconnaître que les certificats pour des domaines à forte valeur présentent un profil de risque différent des renouvellements de routine pour le domaine d'une petite entreprise.

Cette reconnaissance peut se traduire par une validation plus forte du contrôle de domaine, une approbation hors bande, une surveillance des noms à haut risque, une détection d'anomalies, des limites de taux, des restrictions de compte partenaire, une préautorisation du client ou une escalade immédiate lorsqu'un compte revendeur tente d'émettre pour des noms sensibles à l'échelle mondiale.

Les exigences de base modernes et les politiques des magasins de racines traitent ces questions de manière plus explicite que l'écosystème de 2011. Les exigences de base du CA/Browser Forum fournissent désormais des exigences publiques pour l'émission, la validation, la révocation et les opérations des AC serveur. La politique du magasin de racines de Mozilla et le matériel d'application définissent les conditions d'inclusion et de sanction des autorités de certification auxquelles font confiance les produits Mozilla. (CA/Browser Forum Baseline Requirements,Mozilla Root Store Policy,Mozilla CA enforcement policy)

Ces documents actuels ne doivent pas être lus rétroactivement comme la preuve qu'un contrôle spécifique de 2011 a violé une règle actuelle. Ils sont pertinents parce qu'ils montrent comment l'écosystème a appris à traduire la confiance en exigences opérationnelles publiées. La délégation n'est autorisée que si l'AC reste responsable du résultat. Une AC ne peut pas externaliser la signification sociale d'un certificat de confiance par navigateur. Elle peut externaliser des parties de la validation, mais le programme racine du navigateur et l'utilisateur perçoivent toujours le certificat comme relevant de la confiance de l'AC.

C'est là que l'économie des contacts en cas d'abus entre en jeu. L'émission frauduleuse de certificats impose des coûts à des parties qui n'ont pas pris la décision de délégation: les fournisseurs de navigateurs doivent déployer des mises à jour d'urgence; les fournisseurs de systèmes d'exploitation doivent maintenir des magasins de défiance; les opérateurs de sites doivent surveiller les usurpations; les équipes de sécurité doivent vérifier si les utilisateurs ont été interceptés; les utilisateurs finaux doivent s'en remettre à des mesures correctives invisibles.

L'émetteur et son partenaire délégué peuvent supporter des coûts d'enquête et de réputation, mais le travail d'urgence est réparti dans tout l'écosystème.

L'incident pose donc la question de qui paie pour la rapidité. Une émission rapide et à faible friction profite aux vendeurs de certificats et aux clients lorsque tout fonctionne. Lorsqu'un compte délégué échoue, cette même rapidité devient un atout pour l'attaquant, et d'autres parties paient pour ralentir ou annuler le résultat. Un modèle de responsabilité mature exige que l'AC internalise une plus grande part de ce risque par des contrôles plus stricts des partenaires, des portes d'émission à risque plus élevé, des rapports obligatoires et des preuves accessibles aux programmes racine.

La révocation a fonctionné, mais pas suffisamment pour mettre fin au problème

Comodo a déclaré que les neuf certificats avaient été révoqués immédiatement après leur découverte. C'est un fait significatif. La révocation est le premier frein d'urgence lorsqu'un certificat a été émis à tort. Mais l'incident a montré que la révocation n'est pas synonyme de protection fiable des utilisateurs. Un certificat peut être révoqué au niveau de l'AC, inscrit sur une CRL et marqué comme mauvais par OCSP, tout en nécessitant des mises à jour côté client parce que la vérification de la révocation dans le monde réel est inégale.

L'avis de Microsoft a expliqué le problème des parties prenantes avec une clarté inhabituelle. Les vérifications CRL et OCSP sont utiles lorsqu'elles sont accessibles, mais les défaillances réseau et le comportement du client peuvent laisser des lacunes. Microsoft a donc publié des mises à jour pour ajouter les certificats frauduleux au magasin de certificats non approuvés de Windows. Cette décision a fait que la plateforme traite les certificats comme non approuvés même lorsque la récupération ordinaire de la révocation ne pouvait pas fournir de protection. (Avis Microsoft 2524375)

Les normes sous-jacentes aident à expliquer la structure. La RFC 5280 définit le profil de certificat et de CRL X.509 pour l'internet, tandis que la RFC 6960 définit l'OCSP comme un moyen pour les clients d'obtenir des informations sur l'état d'un certificat. Ces outils créent un vocabulaire public pour l'émission et la révocation, mais ils ne garantissent pas que chaque utilisateur, navigateur, appareil, réseau et application applique le même comportement de défaillance au même moment. (RFC 5280,RFC 6960)

Ce fossé d'application est la raison pour laquelle les listes noires des navigateurs ont compté. La mise à jour de Mozilla a placé les certificats HTTPS invalides sur une liste noire pour empêcher toute utilisation abusive. Une liste noire de navigateur est un instrument brutal, mais il est décisif. Il supprime la dépendance à un appel réseau qu'un attaquant pourrait bloquer, intercepter ou faire échouer. Le coût est que les fournisseurs doivent livrer et les utilisateurs recevoir des mises à jour assez rapidement pour que cela compte. (MFSA 2011-11)

L'incident Comodo a donc démontré un modèle d'urgence à plusieurs niveaux. L'AC révoque. Les fournisseurs de navigateurs retirent la confiance localement. Les fournisseurs de systèmes d'exploitation retirent la confiance localement. Les opérateurs de sites surveillent. Les programmes racine interrogent les contrôles de l'AC. Les utilisateurs attendent que la machinerie invisible travaille. L'existence de plusieurs niveaux est une force, mais c'est aussi la preuve qu'aucun niveau unique n'était suffisant.

Ce point devrait modérer les éloges et les critiques. Il est juste de créditer Comodo pour avoir détecté, divulgué et révoqué les certificats assez rapidement pour que le dossier public ne montre pas une large utilisation après la révocation. Il est également juste de dire que la révocation immédiate n'a pas suffi. L'incident a exigé que Mozilla et Microsoft mettent à jour leurs produits parce que la protection des parties prenantes ne pouvait pas être laissée entièrement à la révocation en direct. Ce n'est pas une contradiction. C'est la forme normale de la réponse à un incident de certificat lorsque le mauvais certificat s'est déjà échappé.

L'évolution ultérieure de la Transparence des Certificats donne une autre dimension à la leçon. La RFC 6962 décrivait une conception expérimentale de journalisation publique des certificats, et la RFC 9162 a ensuite spécifié la Transparence des Certificats version 2. La politique de Transparence des Certificats de Google pour Chrome reflète l'idée que les certificats journalisés publiquement sont plus faciles à détecter et à auditer. (RFC 6962,RFC 9162,Politique de Transparence des Certificats de Chrome)

La Transparence des Certificats n'a pas rendu l'incident Comodo de 2011 rétroactivement impossible. Elle a modifié l'environnement de responsabilité pour les incidents ultérieurs en rendant l'émission cachée plus difficile à dissimuler et plus facile à observer pour les propriétaires de domaines, les surveillants et les navigateurs. Le cas Comodo aide à expliquer pourquoi cette visibilité est importante. Si un compte délégué peut émettre pour un domaine à forte valeur, le propriétaire du domaine et l'écosystème des navigateurs ne devraient pas avoir à attendre une découverte privée uniquement.

La confiance du magasin de racines est un service public géré par des programmes privés

L'incident Comodo est aussi un cas de gouvernance du magasin de racines. Une autorité de certification devient puissante parce que les navigateurs et les systèmes d'exploitation incluent ses racines, ou font confiance à des intermédiaires chaînés à des racines, dans des logiciels utilisés par des milliards de personnes. La décision de confiance de l'utilisateur est préchargée. Cela fait des programmes racine des intendants de facto d'une ressource de sécurité publique, même lorsqu'ils sont gérés par des entreprises privées.

Les documents du programme racine de Mozilla énoncent des attentes publiques pour les AC qui cherchent à être incluses dans les produits Mozilla. Chromium et Apple publient leurs propres exigences et politiques de programme racine. Microsoft maintient également un programme de racines de confiance. Ces programmes ne sont pas identiques, mais ils partagent la prémisse centrale que la confiance du navigateur et de la plateforme est conditionnelle. (Politique du magasin de racines de Mozilla,Politique du programme racine Chromium,Programme de certificats racine d'Apple,Programme de racines de confiance Microsoft)

La confiance conditionnelle est plus facile à décrire qu'à appliquer. Supprimer ou restreindre une AC majeure peut casser des sites web, des entreprises, des services gouvernementaux, des portails locaux, des systèmes embarqués et des appareils anciens. Laisser une AC mal contrôlée dans les magasins de confiance peut exposer les utilisateurs à l'interception. Les programmes racine portent donc un fardeau de responsabilité difficile: ils doivent discipliner les AC assez sévèrement pour protéger les utilisateurs, mais de manière assez prévisible pour que le web ne subisse pas de défaillances de disponibilité inutiles.

En 2011, les écrits publics de Mozilla montraient la tension. Le travail immédiat était de mettre sur liste noire les mauvais certificats. Le travail plus large était de discuter de ce qui s'était passé, de demander si des actions supplémentaires étaient nécessaires, et de décider si les contrôles et la réponse de l'AC justifiaient une confiance continue. Ce n'est pas un jugement d'une seule ligne. Cela nécessite des preuves sur le chemin compromis, le confinement, le contrôle des partenaires, la surveillance, l'audit et la probabilité de récidive.

L'incident Comodo n'a pas conduit à un simple effacement public de la confiance en Comodo sur le web. Ce résultat lui-même est informatif. Les programmes racine peuvent tolérer un incident s'ils estiment que l'AC a réagi efficacement, contenu la défaillance, amélioré les contrôles et fourni des preuves suffisantes. Mais la tolérance ne doit pas être confondue avec l'absolution. La confiance continue est une décision de risque prospective, pas une déclaration que l'incident était inoffensif.

Le public a également appris que les programmes de magasin de racines faisaient partie de la chaîne de réponse, et non des consommateurs passifs des rapports des AC. Mozilla a publié un avis de sécurité. Microsoft a publié un avis de sécurité et une mise à jour. Les fournisseurs de navigateurs ont livré du code. Les programmes racine et les fournisseurs ont rendu l'incident intelligible pour les utilisateurs qui n'avaient aucune relation avec le compte AR ou le revendeur Comodo. Le visage public du système de confiance était le navigateur et le système d'exploitation, pas le vendeur de certificats.

Cela crée une division de responsabilité utile. Comodo contrôlait l'émission et la révocation. Les fournisseurs de navigateurs et de plateformes contrôlaient la défiance d'urgence et la protection des utilisateurs. Les programmes racine contrôlaient la confiance future. Les opérateurs de sites contrôlaient la surveillance de leurs domaines. Aucun acteur ne contrôlait l'ensemble du système, mais plusieurs acteurs contrôlaient des portes essentielles. Lorsqu'une AC affirme que sa propre infrastructure n'a pas été compromise, cela peut répondre à une porte. Cela ne répond pas à toutes.

Sectigo a hérité de plus qu'un nom de marque

Le sujet de l'article est Sectigo parce que l'entité actuelle est la marque successeur de l'activité d'autorité de certification de Comodo. Le matériel public de Sectigo décrit le changement de marque de Comodo CA et son activité de cycle de vie des certificats et de confiance numérique. (Comodo CA est maintenant Sectigo,Page à propos de Sectigo)

Cela ne signifie pas que Sectigo actuel est responsable de chaque détail opérationnel de 2011 de la même manière que la direction de Comodo en 2011 était responsable. L'histoire d'entreprise nécessite de la précision. L'incident de 2011 appartient au dossier de l'autorité de certification Comodo. La responsabilité de Sectigo est l'héritage de la confiance, de la position sur le marché, des attentes d'audit, des relations avec les programmes racine et du devoir de montrer que les leçons des incidents antérieurs d'AC ont été absorbées dans les contrôles actuels.

L'historique de confiance est important sur les marchés des autorités de certification parce que les certificats ne sont pas des produits ordinaires. Une AC vend une affirmation que les navigateurs et les parties prenantes accepteront. La valeur de cette affirmation provient de la confiance accumulée: audits, inclusion racine, conformité, disponibilité, services de révocation, reconnaissance de la marque et preuves répétées que les émissions erronées sont traitées sérieusement. Un changement de marque peut clarifier la propriété et la stratégie, mais il ne peut pas effacer l'historique public des incidents de l'ancre de confiance.

Pour les clients, la question pratique n'est pas de savoir si un compte AR de 2011 reste pertinent en tant que risque technique direct en 2026. Ce n'est probablement pas le cas, au sens littéral. La question pratique est de savoir si une AC moderne peut démontrer des contrôles solides sur l'émission déléguée, la sécurité des comptes, les domaines à haut risque, la divulgation d'incidents, la journalisation de la transparence des certificats, la qualité du service de révocation et la communication avec les programmes racine. Un échec historique d'émission déléguée est la preuve de l'importance de ces contrôles.

Pour les programmes racine, la question historique est encore plus nette. Une AC ayant une large empreinte d'émission et de nombreux canaux délégués ou automatisés doit prouver qu'elle peut détecter rapidement les anomalies et fournir des rapports d'incident publics lorsque quelque chose ne va pas. La base de données commune des AC existe en partie pour coordonner les informations publiques sur les AC et la conformité aux programmes racine. (CCADB) La responsabilité publique s'améliore lorsque les rapports d'incident et les preuves de remédiation sont suffisamment visibles pour que les chercheurs, les clients et les parties prenantes puissent évaluer les tendances plutôt que des déclarations isolées.

La question de l'héritage n'est pas propre à Sectigo. L'écosystème des AC a connu de multiples incidents impliquant des émissions erronées, une validation faible, des intermédiaires compromis, des échecs d'audit et des conflits de divulgation. Chaque incident enseigne la même leçon inconfortable: la confiance du navigateur est collante, et le coût de la défiance envers une AC peut être élevé. Cette adhésivité donne une valeur économique aux AC, mais elle élève aussi le niveau de preuve requis lorsque la confiance est endommagée.

Les domaines à forte valeur révèlent l'économie politique de l'abus

Les noms affectés n'étaient pas aléatoires. Les registres Comodo et Microsoft identifient des certificats pour des destinations majeures de communication et d'identité: Google, Yahoo, Skype, les modules complémentaires Mozilla, Microsoft Live et un nom « Global Trustee ». Ces cibles sont significatives parce qu'elles sont des endroits où un utilisateur pourrait s'authentifier, télécharger du code approuvé ou recevoir des communications sensibles.

Le risque technique est l'interception de type homme du milieu. Le risque économique et politique est que quelqu'un d'autre puisse exploiter le système d'AC pour emprunter la légitimité du service victime. Le propriétaire du domaine victime peut avoir sécurisé ses propres serveurs, appliqué HTTPS, géré soigneusement ses clés privées et formé ses utilisateurs à faire confiance à l'icône du cadenas. Un certificat frauduleux émis par une AC de confiance peut contourner une grande partie de ce travail si le trafic est redirigé ou intercepté au niveau du réseau.

C'est pourquoi le pouvoir de délégation DNS apparaît dans le manifeste. Le DNS et les certificats sont des systèmes séparés, mais ils convergent dans la perception de l'utilisateur de « où suis-je? ». Le DNS peut acheminer un utilisateur vers une adresse. Les certificats TLS indiquent au navigateur si le point de terminaison peut présenter une identité acceptée pour le domaine. Si l'un ou l'autre système est subverti, l'utilisateur est en danger. Si les deux peuvent être influencés par un attaquant ou un environnement réseau coercitif, le risque s'aggrave considérablement.

L'économie des contacts en cas d'abus est laide. Un propriétaire de domaine peut n'avoir rien acheté à l'AC ou au revendeur compromis. Il doit tout de même répondre à un certificat frauduleux pour son nom. Les fournisseurs de navigateurs peuvent ne pas avoir causé l'émission. Ils doivent tout de même pousser des mises à jour. Les utilisateurs peuvent avoir tout fait correctement. Ils dépendent tout de même de la révocation, des listes noires et des mises à jour de plateforme. La partie qui bénéficie d'un marché d'émission à faible friction n'est pas toujours celle qui supporte le coût d'urgence lorsque l'émission échoue.

La surveillance moderne par CT aide les propriétaires de domaines à voir plus rapidement les certificats non autorisés, mais la visibilité n'est qu'une partie de l'économie. Quelqu'un doit encore surveiller les journaux, trier les alertes, contacter l'AC, demander la révocation, informer les clients si nécessaire et évaluer si le trafic a pu être intercepté. Pour une grande plateforme, ce travail est faisable. Pour une petite organisation, c'est une autre taxe de sécurité cachée.

Un incident d'AC impliquant un petit domaine peut être tout aussi existenciel pour cette organisation qu'un incident de domaine majeur est embarrassant pour l'écosystème.

Le cas Comodo ne concerne donc pas seulement des marques internet célèbres. Les marques célèbres ont rendu l'événement visible. Le même modèle d'émission déléguée aurait pu nuire à un site d'information dissident, à une petite banque, à un service gouvernemental local, à un portail de santé ou à une page de connexion de fournisseur avec beaucoup moins de surveillance publique. Les systèmes de confiance doivent être jugés sur la manière dont ils protègent les parties prenantes les moins visibles, et pas seulement sur la rapidité avec laquelle ils se coordonnent lorsque la cible est mondialement célèbre.

Une bonne réponse à l'incident a tout de même laissé des questions sans réponse

La réponse publique de Comodo comprenait des faits utiles: la date, la compromission du compte AR, les neuf certificats, les noms de domaine et les numéros de série, la révocation immédiate, la déclaration de surveillance OCSP, le déni de compromission de l'infrastructure AC et HSM, et la tentative ultérieure bloquée. Les fournisseurs de navigateurs et de plateformes ont ajouté des avis publics. Pour 2011, c'est un meilleur dossier que de nombreux incidents.

Cependant, le dossier public laisse des questions sans réponse qui comptent pour la responsabilité. Quelle défaillance de contrôle exacte a permis l'utilisation du compte AR? Quelle authentification et autorisation étaient requises avant et après le 15 mars? Y avait-il des vérifications de domaines à haut risque, et si non, pourquoi pas? Quelle surveillance a remarqué l'émission frauduleuse? Combien de temps les certificats ont-ils existé avant la révocation? Quelles parties ont été notifiées et dans quel ordre? Quelle preuve d'audit indépendante a examiné les contrôles? Qu'est-il arrivé à la relation avec le partenaire délégué?

Certaines de ces réponses peuvent avoir été partagées en privé avec les programmes racine des navigateurs ou les auditeurs. Les preuves privées peuvent être appropriées lorsqu'elles incluent des détails sensibles. Mais la confiance du public ne se construit pas entièrement en privé. Les utilisateurs et les parties prenantes ne peuvent pas évaluer la fiabilité d'une AC si chaque détail significatif de remédiation est confidentiel. L'art consiste à publier suffisamment de preuves pour montrer l'amélioration des contrôles sans fournir un manuel d'exploitation aux attaquants.

La tentative bloquée du 26 mars rend cela particulièrement important. Comodo a déclaré que les nouveaux contrôles ont empêché l'émission frauduleuse lors de la tentative ultérieure. C'est une affirmation solide et utile. Le public n'a cependant reçu qu'une description compacte de ces contrôles.

Un dossier post-incident public plus robuste aurait expliqué les catégories de contrôles sans détails sensibles: authentification plus forte des revendeurs, détection des anomalies d'émission, approbation des domaines à haut risque, rotation des informations d'identification des partenaires, examen d'audit, surveillance supplémentaire et rapport aux programmes racine.

La leçon n'est pas que la réponse publique de Comodo était particulièrement déficiente. C'est que les incidents d'AC exigent un style de post-mortem différent de celui des vulnérabilités logicielles ordinaires. Une AC approuvée par le navigateur fait partie d'une infrastructure d'identité partagée. Lorsqu'elle émet par erreur, ses preuves de récupération doivent satisfaire non seulement ses propres clients, mais aussi les propriétaires de domaines qui n'ont jamais contracté avec elle, les utilisateurs de navigateurs qui n'en ont jamais entendu parler, et les programmes racine qui portent les conséquences de confiance en aval.

Ce que l'incident a changé dans la conversation sur la confiance

L'événement Comodo s'inscrit dans une période plus large où la PKI du web devenait moins disposée à traiter la confiance des AC comme une plomberie de fond invisible. 2011 a également vu la compromission de DigiNotar, une défaillance d'AC beaucoup plus grave qui a conduit à une défiance généralisée. Ensemble, de tels événements ont poussé l'écosystème vers une gestion des incidents publics plus forte, la CT, une meilleure application par les programmes racine et des exigences de base plus détaillées.

Il serait trop simple de dire que Comodo à lui seul a causé ces réformes. Il serait également trop simple de laisser Comodo de côté. L'événement a offert un exemple clair d'émission frauduleuse par autorité déléguée, ciblant des domaines à forte valeur, nécessitant une action d'urgence des navigateurs et des systèmes d'exploitation. C'est exactement le type d'incident qui rend les relations de confiance cachées visibles.

Le paysage des normes et des politiques aujourd'hui reflète ce changement. Les exigences de base du CA/Browser Forum donnent à la validation de domaine et à la révocation une base publique plus formelle. Mozilla, Chromium, Apple et Microsoft publient des attentes de programme racine. La journalisation CT donne aux propriétaires de domaines et aux navigateurs une source de données publiques pour les certificats émis. La CCADB fournit une coordination des programmes racine et des informations publiques sur les AC. Aucun de ces mécanismes n'est parfait, mais ensemble, ils rendent plus difficile pour une AC de traiter un incident comme un simple problème de service client privé. (CA/Browser Forum Baseline Requirements,CCADB,Politique de Transparence des Certificats de Chrome)

La faiblesse restante est la responsabilité par épuisement. L'écosystème peut produire un flot de politiques, d'audits, de fils de discussion de bogues, de messages de liste de diffusion, de rapports d'incident et de problèmes de programme racine. Seule une petite communauté les lit attentivement. Cela crée un paradoxe de transparence: l'information peut être publique, mais la responsabilité pratique dépend encore d'experts ayant le temps de la surveiller. Une AC peut se conformer aux formulaires de divulgation sans que le grand public puisse comprendre ce qui n'a pas fonctionné.

Le cadre de risque de Daniel Kade traverse cette paperasse en demandant qui contrôlait les variables de conséquence. Dans le cas Comodo, la réponse n'est pas mystique. Comodo contrôlait l'émission déléguée, l'authentification des revendeurs, la révocation et la réponse publique. Les fournisseurs de navigateurs et de plateformes contrôlaient la défiance locale et les mises à jour. Les programmes racine contrôlaient l'inclusion continue. Les propriétaires de domaines contrôlaient la surveillance et la communication avec les clients. Les attaquants contrôlaient l'acte malveillant. Les utilisateurs ne contrôlaient presque rien.

Ce dernier fait est la raison pour laquelle la responsabilité des AC doit être stricte. On dit aux utilisateurs de rechercher HTTPS, d'éviter les avertissements et de faire confiance à leur navigateur. Lorsque le système d'AC échoue en amont, les utilisateurs ne peuvent pas inspecter le compte revendeur, la compromission de l'AR, le répondeur OCSP, la CRL, la liste noire ou la discussion du programme racine. Ils s'en remettent aux contrôles institutionnels. Les contrôles institutionnels méritent une responsabilité institutionnelle.

Un meilleur test de responsabilité pour l'émission déléguée

Un test de responsabilité sérieux pour le prochain incident d'émission déléguée devrait commencer avant le nombre de certificats. Premièrement, l'AC devrait pouvoir montrer quels comptes délégués peuvent demander quels certificats, avec quelle authentification, avec quelles restrictions de noms à haut risque et quelle approbation indépendante. Deuxièmement, l'AC devrait pouvoir démontrer une détection d'anomalies pour les demandes impliquant des plateformes majeures, des noms de connexion sensibles, des domaines du secteur public, des services financiers, la distribution de logiciels, les systèmes de santé et d'autres cibles à forte valeur.

Troisièmement, l'AC devrait pouvoir prouver la rapidité et la fiabilité de la révocation. Cela signifie non seulement dire qu'un certificat a été révoqué, mais expliquer comment les parties prenantes ont été protégées lorsque les vérifications de révocation ont échoué ou ont été bloquées. Les fournisseurs de navigateurs et de plateformes peuvent encore avoir besoin de mises à jour de défiance locale, mais l'AC devrait disposer d'un chemin de contact d'urgence et d'un dossier de preuves prêt pour ces fournisseurs.

Quatrièmement, l'AC devrait pouvoir publier un rapport d'incident circonscrit qui indique ce qui s'est passé, ce qui ne s'est pas passé, ce qui reste inconnu et quels contrôles ont changé.

Cinquièmement, les programmes racine devraient pouvoir expliquer pourquoi une confiance continue est appropriée après un incident. Cette explication n'a pas besoin d'exposer des registres d'audit privés, mais elle devrait indiquer les catégories de preuves examinées: confinement, contrôle des partenaires, changements de validation, suivi d'audit, surveillance, performance du service de révocation et transparence de l'incident. Sixièmement, les propriétaires de domaines devraient avoir des moyens pratiques de surveiller les émissions non autorisées et de contacter rapidement les AC lorsque des alertes apparaissent.

L'incident Comodo montre pourquoi chaque élément est important. L'attaquant n'a pas eu besoin de la clé racine de Comodo. Un compte délégué a suffi. La révocation n'a pas supprimé la nécessité d'une action des navigateurs et des systèmes d'exploitation. Les avis publics n'ont pas éliminé toutes les questions sur les contrôles des partenaires. Le faible nombre de certificats n'a pas rendu l'incident mineur, car les cibles étaient des domaines d'identité critique et la confiance affectée était mondiale.

Pour Sectigo, la leçon héritée est simple. Une autorité de certification moderne gagne la confiance non seulement en émettant des certificats à grande échelle, mais en prouvant qu'aucun partenaire, revendeur, chemin d'automatisation ou compte de support ne peut silencieusement retourner cette échelle contre le public. Les incidents historiques ne sont pas une culpabilité permanente. Ils sont une preuve permanente des modes de défaillance contre lesquels il faut concevoir, auditer, surveiller et expliquer.

La lecture la plus défendable du dossier de 2011 n'est ni la panique ni la minimisation. Comodo a détecté et révoqué les certificats frauduleux et a déclaré que son infrastructure racine n'était pas compromise. Mozilla et Microsoft ont tout de même dû livrer des mises à jour protectrices. L'attaquant a montré que l'émission déléguée pouvait créer des identités de confiance pour des domaines majeurs. L'écosystème a appris que la révocation, la confiance racine et le contrôle des revendeurs n'étaient pas des sujets séparés. Ils formaient une seule surface de responsabilité.

C'est pourquoi cet incident figure toujours dans une série sur le risque et la responsabilité quinze ans plus tard. L'artefact visible était un certificat. Le véritable actif était la confiance du public dans la capacité d'un navigateur à distinguer un domaine d'un autre. Une fois que cette confiance peut être empruntée par le biais d'un compte délégué compromis, la question n'est plus de savoir si la clé racine est restée en sécurité dans un HSM. La question est de savoir si tous ceux qui avaient le contrôle pratique de la confiance déléguée l'ont utilisé avec la discipline qu'exige la dépendance mondiale.