Comodo a démontré que le risque lié à l’émission de certificats est aussi un risque de notification et d’application

Résumé

• Comodo a déclaré qu'un compte d'autorité d'enregistrement a été compromis le 15 mars 2011 et utilisé pour émettre neuf certificats frauduleux pour sept domaines; les éléments publics indiquent une défaillance de l'émission déléguée, et non un vol des clés racines ou des modules de sécurité matériels de Comodo.
• La question de la responsabilité allait au-delà des neuf certificats. Les certificats visaient des destinations majeures de connexion, de messagerie, d'extensions de navigateur et de communication, de sorte que tous les navigateurs, plates-formes, réseaux d'entreprise et du secteur public dépendants devaient espérer que la révocation et la défiance d'urgence atteindraient réellement les utilisateurs.
• Mozilla et Microsoft n'ont pas considéré la révocation par l'émetteur comme suffisante en soi. Mozilla a distribué une mise à jour de liste noire et Microsoft a placé les certificats dans le magasin de certificats non approuvés de Windows, car le comportement des CRL et de l'OCSP ne pouvait garantir la protection dans toutes les conditions réseau.
• Comodo contrôlait le modèle d'émission déléguée, l'authentification des partenaires et les preuves de l'incident; les fournisseurs de navigateurs et de systèmes d'exploitation contrôlaient l'application d'urgence; les programmes racines contrôlaient la confiance continue; les propriétaires de domaines et les agences publiques portaient le risque en aval sans voir le compte RA ni les journaux de l'émetteur.
• La leçon durable est que la responsabilité dans la PKI du Web doit mesurer la notification, l'application et la réparation, pas seulement le nombre de certificats. Une CA peut révoquer un certificat rapidement et laisser malgré tout les parties utilisatrices exposées si la défiance n'est pas observable et applicable.

Registre des preuves et leur utilisation

Cet article traite le registre public comme une preuve stratifiée. Les rapports d'incident, les normes, les mesures des navigateurs ou du routage, les documents réglementaires ou de politique, et les conseils actuels des opérateurs sont utilisés pour différentes affirmations. Les sources émanant de l'entreprise sont attribuées comme positions de l'entreprise. Les normes et les conseils ultérieurs sont utilisés pour expliquer les contrôles et présenter les attentes en matière de responsabilité, et non pour inventer des faits privés ou imposer rétroactivement des obligations ultérieures là où le registre public ne le permet pas.

Le petit nombre de certificats cachait un grand problème de délégation

L'incident Comodo est utile précisément parce qu'il ne s'agissait pas d'une énorme brèche en termes de nombre brut. Neuf certificats sont suffisamment peu nombreux pour être listés, inspectés et analysés. Ils suffisent également à montrer comment le pouvoir concentré d'une autorité de certification peut se transformer en risque pour l'écosystème via un compte délégué. Comodo a déclaré que la défaillance provenait d'un compte d'autorité d'enregistrement plutôt que du vol de l'infrastructure de la CA ou des clés protégées par HSM.

Cette distinction réduit la portée de l'affirmation cryptographique, mais elle ne réduit pas celle de la responsabilité. Si un compte délégué peut obtenir des certificats de confiance pour des domaines majeurs, alors le pouvoir pratique d'émission a déjà été distribué au-delà de la cérémonie racine de l'entreprise et dans des canaux opérationnels que les utilisateurs ne voient jamais.

La délégation n'est pas un accident sur le marché des certificats. Les autorités d'enregistrement, les revendeurs, les flux de travail d'entreprise et les chemins d'émission automatisés existent parce que l'émission de certificats doit pouvoir monter en échelle. Le Web ne peut pas fonctionner si chaque demande de certificat est traitée comme une cérémonie sur mesure. Mais l'échelle change l'unité de gouvernance. Une CA n'est pas seulement responsable de la protection de sa clé privée racine; elle est responsable de la surface d'émission par laquelle un certificat devient approuvé par les navigateurs.

Cette surface inclut les comptes partenaires, les permissions de rôle, le flux de validation de domaine, la détection d'anomalies, les contrôles pour les domaines à haute valeur, les enregistrements d'audit, la révocation d'urgence, la divulgation publique et le reporting au programme racine.

Les noms affectés ont rendu le problème évident. Un certificat pour un point de connexion, un point de messagerie ou une destination d'extension de navigateur peut faciliter l'hameçonnage ou une attaque de l'homme du milieu lorsqu'il est combiné à un contrôle du routage, à un contrôle du réseau local, à une interférence DNS, à un logiciel malveillant, à des portails captifs ou à un accès réseau de niveau étatique. Le certificat n'est pas dangereux parce que c'est un fichier.

Il est dangereux parce qu'il permet à une partie non autorisée de présenter une identité cryptographique que les navigateurs et les utilisateurs peuvent accepter comme étant le site prévu. La mauvaise partie peut emprunter la réputation du domaine et la confiance du magasin racine.

C'est pourquoi l'incident relève du pouvoir de délégation DNS même si la défaillance immédiate concernait l'émission de certificats. Le DNS et TLS sont des systèmes distincts, mais l'utilisateur les vit ensemble comme une affirmation sur l'endroit où il se trouve sur Internet. Le DNS peut diriger un utilisateur vers une adresse. TLS indique au navigateur si ce point de terminaison est autorisé à parler au nom d'un nom. Lorsque l'émission de certificats est déléguée via des contrôles faibles, un propriétaire de domaine peut perdre l'assurance pratique de son identité sans changer son propre DNS, ses serveurs ou ses clés privées.

Le problème de continuité du secteur public découle de la même structure. Les agences gouvernementales, les écoles, les hôpitaux et les services municipaux s'appuient souvent sur des navigateurs ordinaires, des magasins de certificats gérés et des points de terminaison TLS opérés par des fournisseurs. Ils ne peuvent pas inspecter indépendamment chaque chemin de délégation d'une CA.

Si un certificat pour un service de connexion ou de mise à jour critique devient suspect, la réponse du secteur public dépend de la capacité des fournisseurs de plates-formes à distribuer la défiance, de la réception de celle-ci par les parcs de terminaux, du comportement correct des passerelles d'inspection et de la capacité des administrateurs à déterminer quels utilisateurs restent exposés. Un petit incident de certificat peut donc devenir un problème de continuité pour des organisations qui n'ont jamais acheté chez l'émetteur compromis.

La révocation était nécessaire mais pas suffisante

Comodo a déclaré que les certificats frauduleux ont été révoqués immédiatement après leur découverte. Ce fait est important et ne doit pas être écarté. La révocation est la première action d'urgence formelle après une erreur d'émission. Le problème est que la révocation est un plan de contrôle, pas une gomme magique. Un client utilisateur doit vérifier l'état, atteindre le service CRL ou OCSP, interpréter le résultat, échouer de manière sécurisée lorsque le résultat est indisponible, et faire tout cela avant que l'attaquant ne puisse exploiter le certificat.

Les clients réels, les boîtiers intermédiaires et les réseaux ne sont pas si uniformes.

Microsoft a expliqué l'écart pratique dans son avis. Même après que l'émetteur ait révoqué les certificats et les ait listés dans les mécanismes de révocation, Microsoft a distribué une mise à jour ajoutant les certificats au magasin local de certificats non approuvés. Cette action a rendu la défiance locale et déterministe pour les systèmes Windows corrigés. Elle a également admis, sur le plan opérationnel, que les vérifications de révocation en direct ne constituaient pas une histoire complète d'application.

Si un attaquant peut bloquer les vérifications d'état, si un client échoue de manière non sécurisée, si un appareil est hors ligne ou si l'inspection d'entreprise modifie le comportement des certificats, la révocation peut rester un signal faible au moment précis où il est le plus nécessaire.

Mozilla a fait la même remarque avec une mise à jour de la liste noire du navigateur. Une liste noire locale est brutale, mais elle fonctionne sans nécessiter une recherche réseau réussie vers l'émetteur. Elle transforme un incident de l'écosystème en une course à la mise à jour logicielle: à quelle vitesse les navigateurs et les systèmes d'exploitation peuvent-ils distribuer la défiance, et à quelle vitesse les utilisateurs et les entreprises peuvent-ils la recevoir? Cette course fait partie de la responsabilité.

Un incident de CA n'est pas réparé lorsque l'émetteur met à jour sa base de données; il est réparé lorsque les parties utilisatrices ne peuvent plus être trompées par le mauvais certificat dans des conditions réalistes.

Cette distinction est importante pour la politique d'application. Si les programmes racines ne mesurent que la rapidité de révocation par l'émetteur, ils passent à côté du coût en aval de la défiance d'urgence. Les équipes de navigateurs doivent trier la liste des certificats, écrire ou mettre à jour la logique de liste noire, tester les versions, publier des avis et absorber les questions sur le risque pour les utilisateurs. Les équipes de systèmes d'exploitation doivent maintenir les magasins de défiance et les chemins de distribution des correctifs. Les propriétaires de domaines doivent surveiller une éventuelle utilisation.

Les équipes d'entreprise doivent vérifier que les clients gérés reçoivent les mises à jour. L'émetteur a créé l'urgence, mais d'autres parties ont effectué une grande partie du travail visible d'application.

Certificate Transparency a modifié par la suite l'environnement de visibilité en rendant les certificats émis plus observables par les propriétaires de domaines et les moniteurs. Il n'a pas résolu rétroactivement Comodo 2011, et il ne supprime pas le besoin de révocation ni de défiance locale. Il déplace cependant la charge de la détection. Un chemin d'émission déléguée caché est moins acceptable lorsque les certificats peuvent et doivent être journalisés, surveillés et contestés rapidement.

Le dossier Comodo explique pourquoi CT n'est pas une transparence décorative; c'est un moyen de rendre le pouvoir d'émission privé publiquement auditable avant que les abus ne deviennent des dommages invisibles.

La notification devait atteindre des parties aux rôles différents

La notification lors d'un incident de certificat n'est pas un message unique à un seul public. La CA doit notifier les programmes racines et les fournisseurs de navigateurs avec suffisamment de détails pour agir. Les fournisseurs de navigateurs et de plates-formes doivent notifier les utilisateurs et les administrateurs dans un langage qui explique si une mise à jour logicielle est nécessaire. Les propriétaires de domaines doivent savoir si leurs noms ont été ciblés. Les agences publiques et les entreprises doivent savoir si les appareils gérés, les appliances d'inspection ou les anciens systèmes nécessitent un traitement particulier.

Les chercheurs en sécurité ont besoin de suffisamment de preuves pour tester les affirmations sans transformer la spéculation en fait.

Le dossier Comodo était inhabituellement concret par rapport aux normes des incidents de l'ICG Web de l'époque. L'entreprise a listé les certificats et domaines affectés, nommé le chemin du compte délégué, affirmé une révocation immédiate, distingué la limite de la clé racine et mis à jour son rapport après une tentative d'intrusion ultérieure bloquée. Mozilla et Microsoft ont publié leurs propres avis. Cette superposition est importante car aucun acteur unique n'avait le public entier. Un rapport de la CA est utile pour les programmes racines et les équipes de sécurité. Un avis de navigateur atteint les utilisateurs de navigateurs.

Un avis Windows atteint les administrateurs de plateforme. Les propriétaires de domaines et les équipes du secteur public ont souvent besoin de tous.

Une bonne notification doit également séparer les preuves de l'assurance. Il est utile que Comodo dise que l'infrastructure de la CA et les clés HSM n'ont pas été compromises, car cela évite une panique excessive concernant chaque certificat de la chaîne. Il est également nécessaire de dire que l'émission déléguée a échoué, car sinon les utilisateurs et les acheteurs pourraient en déduire que l'absence de vol de clé racine signifie que le système de confiance a fonctionné.

Le message correct est plus étroit et plus grave: la racine mathématique est peut-être restée sécurisée tandis que la périphérie d'émission administrative a produit des identités frauduleuses.

La continuité du secteur public dépend de cette précision. Une équipe réseau gouvernementale n'a pas besoin de remplacer tous les certificats du pays parce que neuf certificats frauduleux ont existé. Elle a besoin de savoir si ses navigateurs et systèmes d'exploitation disposent de la mise à jour de défiance pertinente, si les utilisateurs à haut risque ont pu être exposés via des réseaux hostiles, si les outils d'inspection de certificats respecteront la défiance de la plateforme, et si les anciens appareils sans mises à jour restent vulnérables. Une réassurance vague crée une paralysie opérationnelle.

Des numéros de série de certificats spécifiques, des domaines, des canaux de mise à jour et des inconnues résiduelles créent de l'action.

Ce problème de notification est aussi un problème d'application. Si le registre public manque de détails sur les certificats, les fournisseurs de navigateurs ne peuvent pas appliquer rapidement. Si les programmes racines reçoivent des assurances privées mais que le public voit peu de choses, la confiance devient opaque et les soupçons grandissent. Si les propriétaires de domaines l'apprennent par les nouvelles plutôt que par des canaux directs, ils perdent du temps.

L'incident Comodo est donc un avertissement sur le routage des preuves: chaque partie qui doit agir a besoin des bons faits sous la bonne forme avant que l'incident ne puisse être considéré comme contenu.

Les magasins racines sont des programmes privés aux conséquences publiques

L'incident a également mis en lumière le rôle de gouvernance des magasins racines. Les utilisateurs ne constituent pas leur propre liste d'autorités de certification de confiance. Les fournisseurs de navigateurs et de systèmes d'exploitation livrent cette liste. La décision de confiance est préchargée dans les logiciels utilisés pour les services bancaires, la santé, l'éducation, les services publics, l'accès d'entreprise et les communications personnelles. Cela donne aux programmes racines privés des conséquences sur l'infrastructure publique.

Ils peuvent continuer à faire confiance, restreindre, se défier ou exiger une remédiation de la part des CA, et chaque option comporte des coûts de disponibilité et de sécurité.

Continuer à faire confiance après un incident n'est pas une absolution. C'est une décision de risque tournée vers l'avenir. Les programmes racines peuvent décider qu'un émetteur a détecté le problème, révoqué les certificats, divulgué suffisamment et corrigé les contrôles. Ils peuvent également décider que le schéma révèle un risque inacceptable. Dans les deux cas, la décision devrait être fondée sur des preuves.

Les défaillances d'émission déléguée devraient susciter des questions sur l'inventaire des partenaires, l'authentification des comptes, les contrôles pour les noms à haute valeur, la détection d'anomalies, la réponse aux incidents, l'audit externe et la prévention des récidives.

Le coût de la défiance est réel. Retirer une CA majeure des magasins racines peut casser des sites Web, des applications d'entreprise, des portails publics, des systèmes embarqués et des appareils anciens. Ce coût peut rendre les programmes racines prudents. Mais le coût d'une confiance mal placée est également réel: les utilisateurs peuvent être exposés à l'interception ou à l'hameçonnage bien qu'ils fassent tout ce que la formation ordinaire à la sécurité leur dit de faire. Une gouvernance mature doit éviter à la fois les punitions théâtrales et la tolérance sans mordant.

Elle devrait publier des attentes, exiger des rapports d'incident utiles, suivre la remédiation et rendre l'application suffisamment prévisible pour que les CA puissent s'améliorer avant que les utilisateurs ne soient lésés.

Les exigences actuelles du CA/Browser Forum, la politique de Mozilla, la politique Chromium, les documents du programme Apple, les exigences de Microsoft et la coordination du CCADB représentent tous un environnement de gouvernance plus explicite que celui qui existait en 2011. Ils ne doivent pas être utilisés à mauvais escient comme preuve rétroactive qu'un ancien contrôle a violé une clause actuelle. Leur pertinence est prospective: ils montrent que l'écosystème a appris à exprimer la confiance des navigateurs comme une confiance opérationnelle conditionnelle plutôt que comme une réputation permanente.

Pour les clients, la leçon pratique est de demander comment une CA contrôle l'émission déléguée et comment elle prouve la réparation. Pour les acheteurs du secteur public, la question devrait faire partie de la planification des achats et de la continuité. Une autorité de certification peut être un fournisseur à plusieurs niveaux de distance de l'agence, mais sa défaillance peut toujours affecter l'authentification, la distribution de logiciels et les services aux citoyens. Un plan de continuité qui couvre les serveurs mais pas la confiance dans les certificats est incomplet.

Le dossier d'application doit être vérifiable

Le meilleur dossier post-incident n'aurait pas besoin de publier des secrets. Il montrerait les numéros de série des certificats affectés, l'heure exacte de la révocation, la disponibilité du service de statut, l'état de défiance des navigateurs et des plates-formes, la preuve que les privilèges du compte délégué ont été restreints, les contrôles ajoutés pour les domaines à haute valeur, les comptes partenaires examinés et les programmes racines notifiés. Il distinguerait également ce qui a été observé de ce qui a été déduit.

Comodo a fourni plusieurs de ces faits, tandis que d'autres sont restés privés ou distribués sur les canaux des fournisseurs.

Une réparation vérifiable est la norme car la confiance dans les certificats est invisible pour la plupart des utilisateurs. Une personne qui visite une page de connexion ne peut pas savoir si un certificat frauduleux a été révoqué cinq minutes plus tôt, si son navigateur a reçu une liste noire, ou si un proxy d'entreprise a un comportement de défaillance étrange. Elle ne peut que compter sur le système. Le système lui doit donc la preuve que l'application a atteint les points de terminaison qui comptent.

Un tableau de bord de responsabilité utile pour les incidents modernes de CA inclurait le nombre de certificats, les noms affectés, le chemin d'émission, la méthode de validation, le délai de découverte, le délai de révocation, le délai de notification au navigateur, la visibilité dans les journaux CT, le comportement du service de statut, l'état du ticket d'incident du programme racine, la remédiation du compte partenaire et les contrôles de récurrence. L'objectif n'est pas la honte publique. Il s'agit de donner aux parties utilisatrices un moyen de savoir si l'urgence est passée de l'annonce à l'application.

L'incident Comodo devrait également changer la façon dont les organisations pensent au risque « tiers ». Un propriétaire de domaine peut ne jamais contracter avec la CA compromise, et pourtant un certificat de cette CA peut usurper le domaine si les navigateurs font confiance à la chaîne. C'est un type différent d'exposition à un fournisseur: l'inclusion dans le magasin de confiance crée un pool de fournisseurs partagé pour l'ensemble du Web.

Les propriétaires de domaines peuvent réduire le risque grâce à la surveillance CT, aux enregistrements CAA, aux contacts d'incident et à l'escalade rapide, mais ils ne peuvent pas se retirer complètement de l'écosystème de confiance public.

Le constat est que l'événement Comodo a été un test de responsabilité de l'autorité déléguée. L'attaquant a causé l'intrusion. L'émetteur contrôlait le modèle de délégation et les premières étapes de réparation. Les fournisseurs de navigateurs et de systèmes d'exploitation contrôlaient l'application auprès des utilisateurs. Les programmes racines contrôlaient la confiance continue. Les parties prenantes publiques et privées portaient un risque qu'elles ne pouvaient pas observer directement. Un dossier mature de la PKI Web doit rendre tous ces rôles visibles.

L'application est une chaîne, pas un simple événement de révocation

Une réponse à un incident de certificat est souvent décrite comme si l'émetteur possédait l'intégralité de la correction. L'émetteur révoque le certificat, publie un rapport, et l'événement est considéré comme clos. Le dossier Comodo montre pourquoi ce modèle est trop étroit. L'application devait passer par plusieurs couches opérationnellement indépendantes les unes des autres. Comodo pouvait révoquer et notifier. Mozilla pouvait distribuer une liste noire de navigateur. Microsoft pouvait mettre à jour le magasin non approuvé de Windows. Les programmes racines pouvaient évaluer la confiance continue.

Les propriétaires de domaines pouvaient surveiller leurs noms. Les entreprises pouvaient corriger les appareils gérés. Les réseaux du secteur public pouvaient vérifier si les anciens clients ou les appareils d'inspection acceptaient encore les certificats. Aucune de ces étapes n'était facultative si l'objectif était la protection pratique des utilisateurs.

La structure en chaîne change ce que signifie « réponse rapide ». Il ne suffit pas de demander quand Comodo a cliqué sur le bouton de révocation ou mis à jour l'OCSP. La meilleure question est de savoir quand un utilisateur à risque sur un client réaliste a été protégé contre le certificat frauduleux. Cet utilisateur pourrait être sur une machine d'entreprise avec des correctifs différés, un ordinateur de bibliothèque publique, un ancien système d'exploitation, un poste de travail d'agence verrouillé, ou un appareil mobile qui s'appuie sur un magasin de confiance de plateforme.

Le temps écoulé entre la détection par la CA et la défiance sur le point de terminaison est la véritable fenêtre d'application. Le registre public fournit des parties de cette fenêtre à travers les documents de Comodo, Mozilla et Microsoft, mais il ne donne pas une mesure unique consolidée de la protection des points de terminaison.

Cette absence n'est pas inhabituelle. Les incidents de la PKI Web sont distribués par conception. Les fournisseurs de navigateurs ne savent pas toujours quels utilisateurs ont reçu une mise à jour à quel moment. Une CA peut connaître l'état de révocation mais pas l'application au point de terminaison. Un propriétaire de domaine peut voir les journaux CT ou le trafic OCSP, mais pas toutes les tentatives d'interception. Pourtant, l'absence de visibilité parfaite ne doit pas excuser l'absence d'indicateurs utiles.

Les programmes racines et les CA peuvent toujours publier les numéros de série des certificats, les heures de révocation, les heures de divulgation, les heures de notification au navigateur, les références des journaux CT, les chemins de validation affectés et les catégories de remédiation. Ces indicateurs permettent aux organisations dépendantes de décider si leur propre fenêtre de risque reste ouverte.

La chaîne d'application crée également une raison politique pour les mécanismes de défiance locaux. Une vérification de révocation en direct dépend du fonctionnement honnête du réseau pour atteindre le service de statut. Dans un scénario d'homme du milieu, cette hypothèse est fragile. Les magasins de défiance locaux, les listes noires de navigateur et le comportement d'échec strict sont autant de moyens de réduire la dépendance à un chemin réseau qui peut lui-même être attaqué.

L'événement Comodo a rendu cela concret: l'avis de Microsoft a discuté des limites des CRL et de l'OCSP et a tout de même livré une mise à jour de défiance de la plateforme. C'est une admission pratique que la révocation est un signal nécessaire mais non une application suffisante.

Pour la continuité du secteur public, cette chaîne doit être répétée. Les agences ont souvent des fenêtres de correctifs, des tests de compatibilité, des systèmes hérités et des appliances d'inspection de certificats. Une mise à jour urgente de la défiance du navigateur ou du système d'exploitation peut entrer en conflit avec ces processus. Si la mise à jour est retardée, l'agence peut préserver la compatibilité des applications tout en prolongeant l'exposition. Si elle est précipitée, elle peut casser d'anciens services. La bonne préparation n'est pas la panique; c'est l'inventaire.

Quels points de terminaison reçoivent automatiquement les mises à jour du navigateur? Quels systèmes s'appuient sur des magasins de confiance embarqués? Quels proxys terminent TLS? Quels services exposés au public sont surveillés pour les certificats non autorisés? Qui peut approuver une mise à jour d'urgence du magasin de confiance? Ces questions devraient exister avant le prochain incident de certificat.

L'émission déléguée transforme la sécurité des partenaires en infrastructure publique

Le compte RA compromis n'était pas simplement une défaillance de contrôle d'accès interne. C'était une démonstration que la sécurité des partenaires peut devenir une infrastructure publique lorsque le partenaire a un pouvoir d'émission pratique. Un revendeur ou une autorité d'enregistrement peut être économiquement en aval de la CA, mais son compte peut amener les logiciels des parties utilisatrices du monde entier à accepter un certificat. Cette asymétrie devrait changer la façon dont les CA gouvernent leurs partenaires.

L'intégration des partenaires, la force de l'authentification, le moindre privilège, les limites d'émission, l'examen des noms à haut risque, la détection des anomalies et le départ ne sont pas des détails administratifs. Ils font partie du produit de confiance.

Les noms à haute valeur nécessitent un traitement spécial. Un certificat de routine pour un domaine contrôlé par un petit client n'est pas le même risque qu'un certificat pour un point de terminaison majeur de messagerie Web, d'identité, de distribution de logiciels ou d'extension de navigateur. La liste des certificats Comodo illustre cette différence. Si un compte délégué demande soudainement des certificats pour des marques sensibles au niveau mondial avec lesquelles il n'a pas de relation normale, cela devrait déclencher un examen supplémentaire.

Le contrôle peut prendre plusieurs formes: listes préchargées de noms à haut risque, pré-autorisation du propriétaire de la marque, confirmation du propriétaire du domaine, émission différée en attente d'un examen manuel, limites spécifiques au partenaire ou alertes en temps réel à l'équipe de sécurité de la CA. La conception exacte peut varier, mais l'absence de traitement différencié du risque est difficile à défendre après un incident comme celui-ci.

L'émission déléguée soulève également des questions d'audit. Les audits annuels et les déclarations de conformité peuvent passer à côté du risque réel s'ils se concentrent sur les systèmes centraux de la CA tandis que les comptes partenaires ont un large pouvoir opérationnel. Un audit utile échantillonnerait les comptes délégués, examinerait les autorités d'émission qui leur sont attachées, testerait les contrôles pour les domaines à haut risque, inspecterait les exigences d'authentification, vérifierait la couverture de surveillance et examinerait les demandes anormales récentes.

Il vérifierait également si la désactivation d'urgence d'un compte partenaire fonctionne rapidement. La tentative bloquée du 26 mars décrite par Comodo est pertinente car elle implique que les attaquants sont revenus au bord délégué. Les contrôles post-incident devaient résister à une pression répétée, pas seulement réparer un seul compte.

Le marché public devrait s'en soucier car l'émission déléguée est largement invisible pour les acheteurs. Un propriétaire de site Web peut choisir une CA en fonction du prix, de l'automatisation et du support, et non de la posture de sécurité de chaque canal délégué. Un utilisateur a encore moins de choix. Les programmes racines sont donc les parties les plus à même d'imposer une discipline par la politique, les attentes en matière de rapports d'incident et les conséquences pour des faiblesses de contrôle répétées.

L'écosystème CA/Browser Forum, Mozilla, Chromium, Apple, Microsoft et CCADB existe parce que la confiance doit être gouvernée au-dessus du niveau de l'acheteur individuel.

Il existe une version constructive de cette leçon. La délégation peut être sûre lorsqu'elle est délimitée et surveillée. L'automatisation peut améliorer le déploiement des certificats lorsque le contrôle du domaine est vérifié de manière forte. Les revendeurs peuvent bien servir les clients lorsque leur autorité est limitée et auditée. L'incident Comodo ne doit pas être interprété comme un argument selon lequel tout canal délégué est intrinsèquement imprudent.

Il doit être lu comme la preuve que l'émission déléguée doit être traitée comme une fonction de confiance publique chaque fois qu'elle peut produire des certificats de confiance publique.

Ce qu'un post-mortem moderne plus solide inclurait

Un post-mortem moderne pour un incident de type Comodo commencerait par une simple table de preuves: numéro de série du certificat, nom du sujet, chaîne d'émission, horodatage d'émission, horodatage de révocation, statut du journal CT, méthode de validation, compte ou canal délégué, source de la découverte, heure de notification au navigateur et preuve d'utilisation connue. Cette table n'exposerait pas de secrets.

Elle permettrait aux propriétaires de domaines, aux fournisseurs de navigateurs, aux chercheurs et aux entreprises de répondre à la première question opérationnelle: quels objets de confiance ont existé, quand, et qu'a-t-on fait pour les neutraliser?

La deuxième couche expliquerait la défaillance de contrôle sans divulguer les techniques de l'attaquant au-delà de ce qui est utile. Le compte délégué était-il protégé par une authentification à facteur unique? Était-il autorisé à demander n'importe quel domaine? Les domaines à haute valeur étaient-ils signalés? La surveillance a-t-elle détecté l'émission inhabituelle avant une notification extérieure? Les privilèges du partenaire ont-ils été réduits après la découverte? Des comptes partenaires similaires ont-ils été examinés? Quel contrôle empêche désormais le même chemin? Ce ne sont pas des questions punitives.

Ce sont des questions de réparation. Si les réponses restent privées, les observateurs extérieurs ne peuvent pas distinguer une compromission de compte ponctuelle d'une faiblesse systémique de l'autorité déléguée.

La troisième couche mesurerait l'application par l'écosystème. Quand Mozilla, Microsoft, Apple, Chromium et les autres programmes racines ou de plateforme pertinents ont-ils été notifiés? Quelles mises à jour ou mécanismes de défiance ont été livrés? La CA a-t-elle vérifié que les répondeurs de révocation avaient une capacité suffisante et un statut correct? Les réponses OCSP et CRL ont-elles été surveillées pour détecter une tentative d'utilisation après la révocation? Les propriétaires de domaines ont-ils reçu un avis direct? Les administrateurs du secteur public et des entreprises ont-ils reçu des conseils pratiques?

Un incident de certificat n'est pas résolu tant que les parties qui peuvent appliquer la défiance n'ont pas suffisamment de preuves pour le faire.

La quatrième couche aborderait le risque résiduel honnêtement. Si le registre public ne montre pas d'utilisation massive, dites-le. Si un seul certificat a été observé en direct, dites-le et expliquez la méthode d'observation. Si le trafic OCSP n'a pas indiqué d'utilisation après la révocation, dites-le tout en notant les limites de l'OCSP en tant que mécanisme de visibilité. S'il y a des inconnues sur le fait qu'un utilisateur sur un réseau hostile ait accepté un certificat avant les mises à jour, dites-le aussi. L'assurance mature n'est pas le déni de l'incertitude; c'est la désignation disciplinée de ce qui reste inconnu.

Enfin, le post-mortem relierait l'apprentissage de l'incident à la gouvernance. Quelles exigences du programme racine ont changé? Quels contrôles des partenaires ont changé? Quelles règles de détection capturent désormais les noms à haut risque? Quels audits vérifieront ces changements? Quelles métriques seront examinées par la direction? Sans cette couche de gouvernance, l'incident devient une anecdote historique. Avec elle, l'incident devient une carte de contrôle réutilisable pour la prochaine défaillance de l'émission déléguée.

La décision du lecteur concernant la confiance dans les certificats

Un lecteur ne devrait pas quitter le dossier Comodo avec la leçon vague que les autorités de certification devraient être prudentes. La décision exploitable est plus précise: toute organisation qui dépend du TLS public devrait savoir comment elle découvrirait et répondrait à un certificat non autorisé pour son domaine, même si le certificat a été émis par une CA qu'elle n'a pas choisie.

Cela signifie surveiller les journaux de Certificate Transparency, maintenir des contacts de sécurité à jour, utiliser CAA lorsque c'est approprié, tester l'escalade d'incident vers les CA et les fournisseurs de navigateurs, et savoir quels systèmes internes seraient affectés par une urgence de magasin de confiance.

Pour les acheteurs de services de certificats, les questions devraient aller au-delà du prix et de l'automatisation. Comment les comptes délégués sont-ils authentifiés? Les privilèges des revendeurs et des RA sont-ils limités? Quels noms à haute valeur nécessitent un examen supplémentaire? Quelles preuves sont fournies après une erreur d'émission? À quelle vitesse les programmes racines sont-ils notifiés? Comment les services de révocation sont-ils surveillés? Quel est le chemin testé pour la défiance du navigateur lorsque la révocation ne suffit pas?

Ces questions sont des questions ordinaires de gouvernance des fournisseurs dès lors que les certificats sont compris comme une infrastructure d'identité plutôt que comme des renouvellements sur un calendrier.

Pour les programmes racines, l'événement Comodo reste un rappel que la confiance du public devrait être conditionnelle et étayée. Une CA peut répondre rapidement à un incident et avoir tout de même besoin d'un examen plus approfondi de l'autorité des partenaires. L'application ne devrait pas être improvisée au cas par cas; elle devrait être liée à la politique publiée, aux attentes en matière de rapports d'incident et aux preuves de récurrence. Le public n'a pas besoin de chaque détail d'audit confidentiel, mais il a besoin de suffisamment d'éléments pour savoir si l'émission déléguée est plus sûre après l'incident qu'avant.

Pour les opérateurs du secteur public, la décision est orientée vers la continuité. Les navigateurs, proxys, appareils mobiles et systèmes hérités de l'agence reçoivent-ils les mises à jour de défiance des certificats d'urgence suffisamment rapidement? Les administrateurs peuvent-ils identifier si un certificat non autorisé était pertinent pour les services de l'agence? Existe-t-il un moyen de communiquer avec les utilisateurs si un certificat de confiance devient suspect? Une agence publique ne peut pas inspecter l'ensemble de la PKI du Web, mais elle peut préparer la surface de réponse locale.

L'incident Comodo est donc toujours d'actualité car il transforme une abstraction de confiance en questions opérationnelles. Qui peut émettre? Qui peut voir? Qui peut révoquer? Qui peut appliquer? Qui peut prouver que l'application est arrivée? Toute organisation qui ne peut pas répondre à ces questions n'est pas prête pour la prochaine défaillance de confiance dans les certificats.

Un dernier test pratique est de savoir si l'organisation peut nommer son propriétaire de la confiance des certificats. Si la réponse est répartie entre les achats, l'infrastructure, les opérations de sécurité, l'ingénierie Web et le juridique sans propriétaire d'incident, alors un événement de type Comodo sera géré par improvisation. Le propriétaire n'a pas besoin de contrôler chaque programme racine, mais doit savoir comment la preuve passe du moniteur CT au contact CA, au fournisseur de navigateur, puis au point de terminaison de l'entreprise.

Cette propriété fait la différence entre la révocation en tant que déclaration et la révocation en tant que protection.

Ce même propriétaire devrait maintenir un guide de preuves pour les noms à haute valeur. Le guide devrait indiquer quels domaines sont surveillés, quels noms sont trop sensibles pour une émission déléguée ordinaire, quels comptes CA sont approuvés, quels contacts peuvent exiger la révocation, et quels canaux de navigateur et de racine devraient être notifiés si la réponse de la CA n'est pas suffisante.

Il devrait également conserver les preuves post-intervention: quand le certificat est apparu, quand le propriétaire du domaine en a pris connaissance, quand la CA l'a révoqué, quand les mises à jour de la plateforme sont arrivées, et quels utilisateurs auraient encore pu l'accepter avant que l'application ne les atteigne. Le dossier Comodo montre pourquoi ce détail importe. Un certificat frauduleux peut être compté en secondes, mais son risque se mesure par la visibilité, la notification, l'application et la confiance que le même chemin délégué a été fermé.

Typographie

Le constat final

La norme de responsabilité est le contrôle pratique associé à des preuves publiques. Le dossier le plus solide ne prétend pas que chaque acteur contrôlait chaque résultat. Il identifie qui pouvait prévenir la défaillance, qui pouvait la détecter, qui pouvait limiter le rayon d'impact, qui pouvait notifier les parties affectées, qui pouvait réparer la relation de confiance, et quelles preuves démontrent que la réparation a atteint les systèmes et les personnes qui en dépendaient.