L'héritage Comodo de Sectigo montre comment la confiance dans les certificats peut échouer à travers l'émission déléguée

Résumé

• Enregistrement public confirmé:Le rapport d'incident de Comodo indique que le 15 mars 2011, un compte d'autorité d'enregistrement a été compromis et utilisé pour émettre neuf certificats frauduleux pour sept domaines; il précise également 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 révocation. (Rapport d'incident Comodo)
• Réaction des navigateurs et des plateformes:Mozilla, Microsoft et d'autres opérateurs de navigateurs ou de plateformes ont traité l'événement comme plus qu'une simple question de maintenance d'émetteur. Mozilla a diffusé une mise à jour de la liste noire des certificats, Microsoft a publié l'avis de sécurité 2524375 et une mise à jour plaçant les neuf certificats dans le magasin de certificats non approuvés de Windows, et le suivi de Mozilla a décrit la voie compromise de l'autorité d'enregistrement. (Avis Mozilla,Avis Microsoft,Suivi Mozilla)
• Limites de la responsabilité:Les preuves publiques corroborent une défaillance de l'émission déléguée, et non pas la conclusion que les clés racines ou les modules de sécurité matériels de Comodo ont été compromis. Comodo a déclaré que son infrastructure d'AC et ses clés HSM n'étaient pas compromises. Cette distinction restreint la revendication 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 de grande 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 méfiance d'urgence; les programmes racines contrôlaient la confiance continue; les services de parties utilisatrices et les utilisateurs ont subi des conséquences qu'ils ne pouvaient pas observer directement.

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

Les incidents d'autorité de certification sont souvent imaginés comme une compromission cinématographique unique: un attaquant vole une clé privée racine, falsifie le web, et tout le système de confiance s'effondre. L'incident Comodo a été plus banal et plus instructif. Comodo a déclaré que son infrastructure d'AC n'était pas compromise et que les clés de ses modules de sécurité matériels n'étaient pas 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 la 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 part du pouvoir pratique de l'AC est confiée aux comptes partenaires, aux flux de travail des revendeurs, au personnel de validation, aux systèmes automatisés et aux 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é au niveau de la racine mathématique. Il a échoué à la frontière administrative.

La frontière administrative est l'endroit 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 racines ne font pas simplement 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é des services de révocation, les rapports d'incident et la volonté de retirer ou de restreindre la confiance en cas de défaillances récurrentes.

Le dossier Comodo constitue donc un cas de responsabilité utile car 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 particuliers. L'incident n'a pas eu besoin de provoquer une campagne d'interception massive connue pour révéler un problème de gouvernance. Il a montré qu'un compte délégué pouvait transformer le statut racine de navigateur d'une autorité de certification en certificats pour certaines des destinations d'identité les plus sensibles de l'internet.

Les noms eux-mêmes sont porteurs du problème. Un certificat pour un point 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 de réseau local, une interférence de routage, un logiciel malveillant ou un accès réseau de 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 phishing ou des attaques de type « homme du milieu » contre les utilisateurs de navigateurs. (Avis Microsoft 2524375)

La constatation correcte est limitée. Les archives publiques ne montrent pas que les neuf certificats ont été utilisés dans une interception à grande échelle réussie. Comodo a déclaré qu'un seul avait été vu en direct sur internet et que la surveillance du trafic du répondeur OCSP n'avait pas détecté de tentative d'utilisation après révocation. Microsoft et Mozilla ont néanmoins traité l'événement comme urgent car 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. Le même rapport énumère les domaines et les numéros de série et distingue les certificats qu'il avait vus en direct de ceux qu'il n'avait pas vus en direct. (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 brèche de sécurité interne, et que l'attaquant avait utilisé le compte de l'AR avec Comodo pour faire émettre neuf certificats frauduleux. Mozilla a également noté que les certificats avaient été révoqués, que Firefox avait diffusé 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 succinct 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 prévenir toute utilisation abusive. L'enregistrement Bugzilla pour le travail de blocage constitue une trace publique de la réponse côté navigateur. (MFSA 2011-11,Mozilla Bugzilla 642395)

L'avis de sécurité 2524375 de Microsoft a ajouté une couche de 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 avoir suffisamment validé son identité. Microsoft a énuméré les propriétés concernées, décrit les risques d'usurpation, de phishing et d'homme du milieu, et a indiqué que Comodo avait révoqué les certificats et les avait inscrits dans sa liste de révocation de certificats. Microsoft a néanmoins 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 le problème clairement: lorsque les points de terminaison CRL ou OCSP ne peuvent pas être atteints, les navigateurs et les applications peuvent continuer de manière à exposer les utilisateurs. Les certificats avaient été révoqués par l'émetteur, mais le logiciel de partie utilisatrice avait encore besoin d'une logique de méfiance locale pour éliminer l'incertitude. C'est le moment où 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 déjoué une intrusion dans un compte utilisateur revendeur le 26 mars, et que les nouveaux contrôles mis en œuvre après l'incident du 15 mars avaient éliminé tout risque d'émission de certificats frauduleux. Il a également déclaré croire que l'attaque provenait du même auteur. Cette mise à jour n'est pas un simple aparté. Elle suggère une tentative répétée contre l'émission déléguée après la première compromission, et place les contrôles post-incident sous surveillance. (Rapport d'incident Comodo)

Pour un registre de responsabilité publique, 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, la revendication de révocation, la réponse du navigateur et du système d'exploitation, et l'existence d'une tentative ultérieure bloquée. Elle ne publie pas un rapport d'analyse forensique indépendant complet, la méthode d'accès initiale exacte, l'environnement de contrôle complet du revendeur, les conséquences de l'audit, les communications privées avec les programmes racines, ou 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 défense de responsabilité la plus faible: l'AC racine n'a pas été compromise, donc la défaillance se situe ailleurs. Techniquement, cela peut être vrai. Du point de vue de la 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 confiance pour les navigateurs.

Cela ne signifie pas que tout modèle délégué est inconsidéré. 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 des certificats rapidement. 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 visaient 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 de grande valeur présentent un profil de risque différent de celui des renouvellements de routine pour un domaine de petite entreprise. Cette reconnaissance peut se traduire par une validation de contrôle de domaine plus forte, 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 règles de base modernes et les politiques des magasins de certificats racines abordent ces questions de manière plus explicite que ne le faisait l'écosystème de 2011. Les Exigences de Base du CA/Browser Forum fournissent désormais des exigences publiques pour l'émission de certificats serveur, la validation, la révocation et les opérations des AC. La politique du magasin de certificats racines de Mozilla et les documents de mise en application définissent les conditions d'inclusion et de discipline des autorités de certification auxquelles les produits Mozilla font confiance. (Exigences de Base du CA/Browser Forum,Politique du magasin racine de Mozilla,Politique de mise en application des AC de Mozilla)

Ces documents actuels ne doivent pas être lus rétrospectivement comme la preuve qu'un contrôle spécifique de 2011 violait une règle actuelle. Ils sont pertinents car 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 pour navigateur. Elle peut externaliser une partie de la validation, mais le programme racine du navigateur et l'utilisateur continuent de percevoir le certificat comme la confiance de l'AC.

C'est là que l'économie des contacts en cas d'abus entre en jeu. L'émission de certificats frauduleux impose des coûts à des parties qui n'ont pas pris la décision de délégation: les fournisseurs de navigateurs doivent diffuser des mises à jour d'urgence; les fournisseurs de systèmes d'exploitation doivent maintenir des magasins de méfiance; les exploitants de sites doivent surveiller l'usurpation; les équipes de sécurité doivent enquêter pour savoir si les utilisateurs ont été interceptés; les utilisateurs finaux doivent compter sur une remédiation invisible. 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 savoir qui paie pour la rapidité. Une émission rapide et sans friction profite aux vendeurs de certificats et aux clients lorsque tout fonctionne. Lorsqu'un compte délégué échoue, la 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 davantage ce risque grâce à des contrôles de partenaires plus stricts, des portes d'émission à risque plus élevé, des rapports obligatoires et des preuves disponibles pour les programmes racines.

La révocation a fonctionné, mais pas assez pour résoudre le problème

Comodo a déclaré que les neuf certificats ont é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é mal émis. Mais l'incident a montré que la révocation n'est pas synonyme de protection fiable de l'utilisateur. Un certificat peut être révoqué au niveau de l'AC, inscrit dans une CRL, et marqué comme mauvais par l'OCSP, tout en nécessitant des mises à jour côté client parce que la vérification de la révocation en conditions réelles est inégale.

L'avis de Microsoft a expliqué le problème de la partie utilisatrice 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 des clients 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 en sorte 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 de l'infrastructure à clé publique X.509 de l'internet, tandis que la RFC 6960 définit l'OCSP comme un moyen pour les clients d'obtenir des informations sur l'état des certificats. 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)

C'est cet écart de mise en application qui explique pourquoi les listes noires des navigateurs étaient importantes. 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 diffuser et les utilisateurs recevoir les mises à jour assez rapidement pour que cela compte. (MFSA 2011-11)

L'incident Comodo a donc démontré un modèle d'urgence à plusieurs couches. L'AC révoque. Les fournisseurs de navigateurs retirent la confiance localement. Les fournisseurs de systèmes d'exploitation retirent la confiance localement. Les exploitants de sites surveillent. Les programmes racines remettent en question les contrôles de l'AC. Les utilisateurs attendent que la machinerie invisible fonctionne. L'existence de plusieurs couches est une force, mais c'est aussi la preuve qu'aucune couche unique n'était suffisante.

Ce point devrait tempérer les éloges et les critiques. Il est juste de créditer Comodo pour avoir détecté, divulgué et révoqué les certificats suffisamment rapidement pour que les archives publiques ne montrent pas une utilisation généralisée après révocation. Il est également juste de dire que la révocation immédiate n'a pas suffi. L'incident a obligé Mozilla et Microsoft à mettre à jour leurs produits parce que la protection de la partie utilisatrice ne pouvait pas être entièrement laissée à la révocation en direct. Ce n'est pas une contradiction. C'est la forme normale d'une 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 perspective à la leçon. La RFC 6962 décrivait une conception de journalisation publique expérimentale pour les certificats, et la RFC 9162 a spécifié plus tard la version 2 de la Transparence des Certificats. La politique de Transparence des Certificats de Google pour Chrome reflète l'idée que les certificats consigné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 moniteurs et les navigateurs. Le cas Comodo aide à expliquer pourquoi cette visibilité est importante. Si un compte délégué peut émettre pour un domaine de grande valeur, le propriétaire du domaine et l'écosystème des navigateurs ne devraient pas avoir à attendre uniquement une découverte privée.

La confiance dans les magasins de certificats racines est un service public géré par des programmes privés

L'incident Comodo est également un cas de gouvernance des magasins de certificats racines. Une autorité de certification devient puissante parce que les navigateurs et les systèmes d'exploitation incluent ses racines, ou font confiance aux intermédiaires chaînés aux 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 racines des gestionnaires 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 à obtenir la confiance dans les produits Mozilla. Chromium et Apple publient leurs propres exigences et politiques de programme racine. Microsoft maintient également un programme racine de confiance. Ces programmes ne sont pas identiques, mais ils partagent le principe central selon lequel la confiance du navigateur et de la plateforme est conditionnelle. (Politique du magasin racine de Mozilla,Politique du programme racine Chromium,Programme de certificat racine Apple,Programme racine de confiance Microsoft)

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

En 2011, les écrits publics de Mozilla montraient cette tension. Le travail immédiat consistait à mettre sur liste noire les mauvais certificats. Le travail plus large était de discuter de ce qui s'était passé, de demander si des mesures supplémentaires étaient nécessaires, et de décider si les contrôles et la réponse de l'AC justifiaient le maintien de la confiance. Ce n'est pas un jugement en une 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 à une simple éradication publique de la confiance Comodo sur le web. Ce résultat lui-même est informatif. Les programmes racines peuvent tolérer un incident s'ils estiment que l'AC a réagi efficacement, a contenu la défaillance, a amélioré les contrôles et a fourni suffisamment de preuves. Mais la tolérance ne doit pas être confondue avec l'absolution. Le maintien de la confiance est une décision de risque prospective, et non une déclaration selon laquelle l'incident était inoffensif.

Le public a également appris que les programmes de magasins de certificats 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 diffusé du code. Les programmes racines 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 séparation utile des responsabilités. Comodo contrôlait l'émission et la révocation. Les fournisseurs de navigateurs et de plateformes contrôlaient la méfiance d'urgence et la protection des utilisateurs. Les programmes racines contrôlaient la confiance future. Les exploitants 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 déclare 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. Les documents publics de Sectigo décrivent 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 l'actuel Sectigo 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, la position sur le marché, les attentes d'audit, les relations avec les programmes racines et le devoir de montrer que les leçons des incidents antérieurs d'AC ont été intégrées dans les contrôles actuels.

L'historique de confiance est important sur le marché 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 utilisatrices 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 erreurs d'émission 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. Il ne l'est probablement pas, 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 des incidents, la journalisation de la transparence des certificats, la qualité des services de révocation et la communication avec les programmes racines. Une défaillance historique de l'émission déléguée est la preuve de l'importance de ces contrôles.

Pour les programmes racines, la question historique est encore plus aiguë. Une AC avec une empreinte d'émission importante 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 tourne mal. La Base de Données Commune des AC existe en partie pour coordonner les informations publiques sur les AC et la conformité aux programmes racines. (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 utilisatrices 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 erreurs d'émission, une validation faible, des intermédiaires compromis, des échecs d'audit et des litiges de divulgation. Chaque incident enseigne la même leçon inconfortable: la confiance du navigateur est collante, et le coût de la méfiance envers une AC peut être élevé. Cette adhérence donne aux AC une valeur économique, mais elle élève également la norme de preuve lorsque la confiance est endommagée.

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

Les noms concernés n'étaient pas aléatoires. Les archives 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 car ce sont des endroits où un utilisateur peut s'authentifier, télécharger du code de confiance 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 les clés privées et formé les utilisateurs à faire confiance à l'icône de 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. DNS et certificats sont des systèmes distincts, mais ils convergent dans le sentiment de l'utilisateur de « où suis-je? ». Le DNS peut diriger 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 devient bien pire.

L'économie des contacts en cas d'abus est laide. Un propriétaire de domaine peut n'avoir rien acheté auprès de l'AC ou du revendeur compromis. Il doit néanmoins répondre à un certificat frauduleux pour son nom. Les fournisseurs de navigateurs peuvent ne pas avoir causé l'émission. Ils doivent néanmoins diffuser des mises à jour. Les utilisateurs peuvent avoir tout fait correctement. Ils dépendent néanmoins de la révocation, des listes noires et des mises à jour de plateforme. La partie qui bénéficie d'un marché de l'é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 aurait 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 existentiel pour cette organisation qu'un incident sur un domaine majeur est embarrassant pour l'écosystème.

Le cas Comodo ne concerne donc pas seulement les 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 d'examen public. Les systèmes de confiance doivent être jugés par la manière dont ils protègent les parties utilisatrices les moins visibles, et pas seulement par 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 brèche du compte AR, les neuf certificats, les noms de domaine et numéros de série, la révocation immédiate, le langage de surveillance OCSP, le déni de compromission de l'infrastructure d'AC et des 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.

Pourtant, les archives publiques laissent des questions sans réponse qui importent pour la responsabilité. Quelle défaillance de contrôle exacte a permis l'utilisation du compte AR? Quelles 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? Quelle surveillance a remarqué l'émission frauduleuse? Combien de temps les certificats ont-ils existé avant révocation? Quelles parties ont été notifiées dans quel ordre? Quelles preuves d'audit indépendant ont examiné les contrôles? Qu'est-il arrivé à la relation avec le partenaire délégué?

Certaines de ces réponses ont peut-être été partagées en privé avec les programmes racines 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 utilisatrices ne peuvent pas évaluer la fiabilité d'une AC si chaque détail significatif de remédiation est confidentiel. L'art est de 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 de nouveaux contrôles ont empêché l'émission frauduleuse lors de la tentative ultérieure. C'est une affirmation forte et utile. Le public n'a cependant reçu qu'une description compacte de ces contrôles. Un dossier public post-incident plus robuste aurait expliqué les catégories de contrôles sans détails sensibles: authentification plus forte des revendeurs, détection d'anomalies d'émission, approbation des domaines à haut risque, rotation des identifiants des partenaires, revue d'audit, surveillance supplémentaire et rapports aux programmes racines.

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 de confiance pour 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 racines qui supportent 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 apporté la compromission DigiNotar, une défaillance d'AC beaucoup plus grave qui a conduit à une large méfiance. Ensemble, de tels événements ont poussé l'écosystème vers une gestion plus forte des incidents publics, la CT, une meilleure application des programmes racines et des exigences de base plus détaillées.

Il serait trop simple de dire que Comodo 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 de grande valeur, nécessitant une action d'urgence des navigateurs et des systèmes d'exploitation. C'est exactement le type d'incident qui rend visibles les relations de confiance cachées.

Le paysage des normes et des politiques reflète aujourd'hui 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 les attentes des programmes racines. La journalisation CT fournit aux propriétaires de domaines et aux navigateurs une source de données publique pour les certificats émis. La CCADB assure la coordination des programmes racines et les 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 privé de service client. (Exigences de Base du CA/Browser Forum,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 bogues, de messages sur des listes de diffusion, de rapports d'incident et de problèmes de programmes racines. 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 tandis que le grand public reste incapable de comprendre ce qui a mal tourné.

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 méfiance locale et les mises à jour. Les programmes racines 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 le 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 brèche de l'AR, le répondeur OCSP, la CRL, la liste noire ou la discussion du programme racine. Ils se fient à des 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 être en mesure de montrer quels comptes délégués peuvent demander quels certificats, sous quelle authentification, avec quelles restrictions de noms à haut risque et quelle approbation indépendante. Deuxièmement, l'AC devrait être en mesure de montrer la 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 de grande valeur.

Troisièmement, l'AC devrait être en mesure de 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 utilisatrices 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 méfiance locale, mais l'AC devrait avoir un chemin de contact d'urgence et un dossier de preuves prêt pour ces fournisseurs. Quatrièmement, l'AC devrait être en mesure de 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 été modifiés.

Cinquièmement, les programmes racines devraient être en mesure d'expliquer pourquoi le maintien de la confiance est approprié après un incident. Cette explication n'a pas besoin d'exposer les dossiers d'audit privés, mais elle devrait indiquer les catégories de preuves examinées: confinement, contrôle des partenaires, modifications 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 disposer de moyens pratiques pour surveiller les émissions non autorisées et pour 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é le besoin d'action des navigateurs et des systèmes d'exploitation. Les avis publics n'ont pas supprimé toutes les questions sur les contrôles des partenaires. Le petit nombre de certificats n'a pas rendu l'incident petit, parce que les cibles étaient des domaines critiques pour l'identité et que 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 néanmoins dû diffuser des mises à jour protectrices. L'attaquant a montré que l'émission déléguée pouvait créer des identités de confiance pour les navigateurs 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 distincts. Ils formaient une seule surface de responsabilité.

C'est pourquoi cet incident appartient toujours à 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 un contrôle pratique sur la confiance déléguée l'ont utilisée avec la discipline qu'exige la dépendance mondiale.