DigiNotar 2011 : compromission d’une autorité de certification

À l’été 2011, l’autorité de certification (AC) néerlandaise DigiNotar a émis 531 certificats frauduleux, s’en est aperçue et n’a rien dit. L’un d’eux, valable pour *.google.com, a servi à intercepter le trafic Gmail d’environ 300 000 internautes, presque tous en Iran ; trois semaines après la découverte publique, l’entreprise était en faillite. L’affaire reste la démonstration la plus nette de ce que le WebPKI (l’infrastructure à clés publiques du Web, Public Key Infrastructure) garantit, et surtout de ce qu’il ne garantit pas.

→ Lire l’explication complète de la marmotte

DigiNotar, autorité du WebPKI et de PKIoverheid

DigiNotar, installée à Beverwijk, était depuis janvier 2011 une filiale de VASCO Data Security. Elle cumulait deux rôles. D’un côté, une autorité du WebPKI : sa racine figurait dans les magasins de confiance des navigateurs et des systèmes d’exploitation, donc n’importe quel certificat qu’elle signait était accepté partout. De l’autre, une autorité sous-jacente de PKIoverheid, la PKI de l’État néerlandais, qui servait aux services publics et à leurs usagers.

Ce cumul a pesé lourd dans la réponse. Retirer une racine commerciale ne fait souffrir que ses clients ; retirer une autorité qui porte les certificats d’un État revient à couper des téléservices publics. Les éditeurs ont d’abord ménagé la branche PKIoverheid, et c’est l’État néerlandais lui-même qui a retiré sa confiance à DigiNotar le 3 septembre 2011, avant de reprendre la gestion opérationnelle de ses certificats. La manière dont chaque éditeur gère ses racines (et leur retrait) est détaillée dans le comparatif des magasins de confiance des navigateurs.

Operation Black Tulip : chronologie de l’intrusion

Le rapport de Fox-IT, baptisé « Operation Black Tulip », établit le déroulé suivant :

17 juin 2011 : le périmètre réseau de DigiNotar est franchi.
1er juillet 2011 : l’attaquant atteint le segment « Secure-net », celui des serveurs d’autorité. Les huit serveurs qui portaient les autorités seront tous compromis.
10 juillet 2011 : première émission frauduleuse réussie. C’est aussi la date du certificat qui comptera, celui pour *.google.com, numéro de série 05:e2:e6:a4:cd:09:ea:54:d6:65:b0:75:fe:22:a2:56.
19 juillet 2011 : DigiNotar sait qu’elle a été pénétrée. Elle révoque une partie des certificats frauduleux et ne prévient personne.
27-28 août 2011 : un internaute iranien signale sur le forum d’entraide de Google que Chrome refuse le certificat de Gmail.
30 août 2011 : Fox-IT est appelé.
3 septembre 2011 : l’État néerlandais retire sa confiance à DigiNotar.
5 septembre 2011 : publication du rapport intermédiaire de Fox-IT.
6 septembre 2011 : Firefox 6.0.2 retire la racine DigiNotar ; Microsoft publie une mise à jour qui la sort de son magasin de confiance ; Chrome la bloque.
20 septembre 2011 : le tribunal de Haarlem déclare DigiNotar en faillite.

Au total, 531 certificats frauduleux ont été identifiés : google.com et *.google.com, mais aussi addons.mozilla.org, Skype, Yahoo, WordPress, Tor, et des noms de la CIA, du MI6 et du Mossad. L’attaquant, qui signait « ComodoHacker », avait déjà frappé un revendeur de Comodo en mars 2011 ; il a laissé une signature en persan dans certains certificats. Discrétion relative, donc, mais suffisante : sept semaines entre la première émission et le signalement, sans qu’aucun mécanisme du WebPKI ne lève le petit doigt.

Exemple : l’interception de Gmail et le refus de Chrome

Le schéma suit le trajet du certificat *.google.com frauduleux, de sa signature jusqu’au poste de la victime. Il faut y lire deux points : la ligne où la validation X.509 ordinaire laisse passer l’attaque, et celle où l’épinglage de Chrome l’arrête.

Le relais d’interception tient deux sessions TLS (Transport Layer Security) : l’une avec la victime, sous le certificat frauduleux, l’autre avec les vrais serveurs de Google. Entre les deux, le trafic circule en clair pour l’attaquant. Pour un navigateur ordinaire, rien ne cloche : la chaîne remonte à une racine du magasin, le nom figure dans le certificat, les dates sont bonnes. Le cadenas s’affiche.

Chrome, lui, embarquait depuis sa version 13 (mai 2011) une liste des clés publiques autorisées pour les domaines de Google, compilée dans le binaire. Un certificat parfaitement valide au sens de la chaîne X.509, mais signé par une autorité hors de cette liste, était rejeté. C’est ce rejet qui a donné l’alerte.

Dernier détail, d’une ironie qui se passe de commentaire : c’est le répondeur OCSP (Online Certificate Status Protocol) de DigiNotar, interrogé par les navigateurs des victimes pour savoir si le certificat était révoqué, qui a permis d’estimer leur nombre. Le mécanisme de révocation n’a protégé personne, mais il a tenu le registre des présents.

Le WebPKI, un « ou » logique : surface d’attaque des autorités de confiance

Le point à retenir de l’affaire tient en une phrase : dans le WebPKI, n’importe quelle autorité du magasin de confiance peut émettre pour n’importe quel nom. La validation est un « ou » logique entre toutes les racines. La sécurité de google.com ne dépendait donc pas de l’autorité choisie par Google, mais de la moins bien tenue des autorités acceptées par le navigateur. Et le propriétaire du nom n’a aucun droit de veto.

Le schéma ci-dessous reprend les contrôles d’un navigateur sur une chaîne présentée ; la dernière question est celle que le protocole ne pose jamais.

Le SAN (Subject Alternative Name) est l’extension qui porte les noms couverts par le certificat ; le détail des extensions est dans la page consacrée aux extensions X.509, et le modèle de confiance d’ensemble dans Relier une clé à une identité.

Les attaques connues contre ce modèle se rangent en quatre familles, avec des contre-mesures qui n’ont pas la même portée :

Compromission d’une autorité (DigiNotar) : l’attaquant signe directement. Contre-mesure côté autorité : cloisonnement, journalisation protégée, contrôle des demandes de signature. Contre-mesure côté propriétaire du nom : aucune préventive, seulement la détection (Certificate Transparency).
Compromission d’un revendeur ou d’une autorité d’enregistrement (Comodo, mars 2011) : l’attaquant obtient une émission légitime par un canal mal protégé. Même contre-mesure de détection.
Validation de domaine trompée : détournement DNS (Domain Name System) ou de routage BGP (Border Gateway Protocol) pendant le défi de validation. Contre-mesures : validation depuis plusieurs points du réseau, DNSSEC (DNS Security Extensions) sur la zone.
Intermédiaire délégué abusif : une autorité signe un intermédiaire pour un tiers qui s’en sert pour intercepter. Contre-mesure : contraintes de nom dans l’intermédiaire et audit, voir le cycle de vie d’une autorité intermédiaire.

L’enregistrement CAA (Certification Authority Authorization, publié dans le DNS) permet de lister les autorités autorisées pour un nom, et sa vérification est obligatoire pour les autorités depuis 2017. Il réduit le « ou » pour les autorités honnêtes. Une autorité compromise, par définition, ne consulte rien du tout : CAA protège contre l’erreur, pas contre l’intrusion.

Révocation OCSP et CRL : pourquoi seul le retrait de la racine a fonctionné

La révocation n’a joué aucun rôle utile dans la réponse, et pas par malchance. Trois raisons structurelles :

On ne révoque que ce qu’on connaît. Sans journalisation centralisée protégée, DigiNotar ne disposait pas d’une liste fiable de ce qui avait été signé. Une partie des certificats frauduleux a été révoquée en juillet ; les autres ont continué de servir.
La vérification est contournable. Les navigateurs traitent l’échec d’une requête OCSP ou d’un téléchargement de CRL (Certificate Revocation List) en « soft-fail » : pas de réponse, pas de blocage. Un attaquant placé sur le chemin réseau peut filtrer ces requêtes ; dans le cas iranien, il ne s’en est même pas donné la peine.
La révocation est émise par l’autorité. Quand l’autorité est l’objet compromis, lui demander de signer la liste de ses propres fautes revient à confier l’audit au cambrioleur.

Le seul levier efficace a été le retrait de la racine par les éditeurs de navigateurs et de systèmes : Firefox 6.0.2, la mise à jour Microsoft, le blocage dans Chrome. Une mise à mort hors de tout mécanisme du protocole, qui passe par le canal de mise à jour logicielle. Les détails de la mécanique OCSP et CRL sont dans la comparaison CRL et OCSP, et la thèse générale dans l’éditorial La révocation qui ne marche pas.

Position à retenir : la révocation est une mesure d’hygiène pour un incident limité et connu (une clé de serveur perdue, un certificat mal émis). Face à la compromission d’une autorité, elle ne sert à rien ; la réponse réelle est le retrait de confiance de la racine, et elle dépend des éditeurs, pas de l’autorité ni du titulaire du certificat. Corollaire : un client qui ne reçoit pas les mises à jour de magasin de confiance (équipement embarqué, système figé, environnement isolé sans politique de mise à jour) a continué de faire confiance à DigiNotar longtemps après sa faillite.

Épinglage de clés : le contrôle qui a détecté l’attaque, et son prix

Ce qui a arrêté l’attaque est un contrôle qui ignore le WebPKI. L’épinglage remplace le « ou » de toutes les racines par une liste blanche : pour tel nom, seules telles clés publiques sont acceptées. Chrome l’appliquait aux domaines de Google parce que Google maîtrisait les deux bouts, le navigateur et les serveurs. Vingt ans de PKI apprennent que les défenses qui marchent sont souvent celles qui font confiance à un peu moins de monde, ce qui se vend mal comme slogan.

Le prix est connu, et il a enterré la généralisation. L’épinglage dynamique annoncé par en-tête HTTP, le HPKP (HTTP Public Key Pinning), a été abandonné par les navigateurs : une erreur d’épinglage rend le site injoignable pour tous les clients qui ont mémorisé la mauvaise clé, pendant toute la durée annoncée, et un attaquant qui prend la main sur un serveur peut épingler sa propre clé pour prendre le domaine en otage. Changer d’autorité en urgence (exactement ce qu’ont dû faire les clients de DigiNotar) devient impossible si l’ancienne clé est épinglée sans secours.

Recommandation assumée :

Site web public : pas d’épinglage. La détection passe par Certificate Transparency et la prévention partielle par CAA.
Application mobile ou client lourd dont on contrôle le code et le canal de mise à jour : épinglage acceptable, sur la clé publique, le SPKI (Subject Public Key Info), et jamais sur le certificat, avec au moins une clé de secours épinglée et hors ligne, et un mécanisme de désactivation distribuable sans attendre un cycle de publication.
Flux internes, API (Application Programming Interface) entre services, mTLS (TLS mutuellement authentifié) : la forme la plus saine de l’épinglage consiste à ne pas utiliser le magasin public du tout, et à configurer un magasin de confiance réduit à la racine privée de l’organisation. Même effet, sans la fragilité.

Les modes de défaillance en production sont détaillés dans Certificate pinning : risques opérationnels.

Certificate Transparency : rendre l’émission visible, pas l’empêcher

Certificate Transparency (CT), proposé par Ben Laurie et Adam Langley chez Google en 2011-2012 et normalisé par la RFC 6962 (Request for Comments, juin 2013), est la réponse structurelle à l’affaire. Le principe : chaque certificat est inscrit dans des journaux publics, en ajout seul, dont l’intégrité se vérifie par arbre de Merkle. Le journal renvoie un SCT (Signed Certificate Timestamp), une promesse signée d’inscription, que le certificat ou la poignée de main TLS doit présenter. Chrome exige cette preuve pour tout certificat émis depuis le 30 avril 2018.

Ce que CT change : une autorité ne peut plus émettre en secret un certificat accepté par les navigateurs qui appliquent la politique. L’émission silencieuse façon DigiNotar laisserait aujourd’hui 531 entrées publiques, horodatées et signées.

Ce que CT ne change pas :

CT n’empêche pas l’émission. Le certificat frauduleux reste valide et utilisable jusqu’au retrait de confiance de l’autorité ou à sa révocation.
La détection reste à la charge de chacun. Personne ne surveille les noms d’une organisation à sa place. Un journal public que personne ne lit a la valeur probante d’un registre d’entrée sans gardien.
Le délai d’intégration existe. Un SCT est une promesse d’inscription dans un délai maximal, le MMD (Maximum Merge Delay), typiquement vingt-quatre heures ; la fenêtre d’exploitation n’est pas nulle.
Les clients hors politique CT (bibliothèques TLS d’applications, équipements) ne vérifient rien.

Le fonctionnement détaillé des journaux et des moniteurs est dans Certificate Transparency.

Exemple : surveiller ses noms dans les journaux CT

La requête suivante interroge l’agrégateur public crt.sh pour tous les certificats couvrant un domaine et ses sous-domaines, et sort une ligne par couple (date, émetteur, noms). Remplacer example.com par le domaine surveillé.

# %25 est le joker "%" encodé : couvre example.com et tous ses sous-domaines
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' \
  | sort -u
# Lire la colonne issuer_name : tout émetteur absent de l'enregistrement CAA
# du domaine doit déclencher une alerte et une investigation.

En exploitation, cette vérification se branche sur un moniteur qui suit les journaux en continu et alerte sur un émetteur inattendu, plutôt que sur une commande lancée à la main quand on y pense. La règle d’alerte utile n’est pas « nouveau certificat » (le renouvellement automatique en produit tous les deux mois) mais « certificat d’un émetteur hors liste » ou « nom inconnu de l’inventaire ».

Exploiter une autorité de certification : les prérequis que DigiNotar n’avait pas

Les défaillances relevées par Fox-IT forment une liste de prérequis à l’envers. Pour une autorité, privée ou publique :

Cloisonnement d’administration. Les serveurs d’autorité étaient tous dans un seul domaine Windows : un compte d’administration compromis donnait l’ensemble. Une racine se garde hors ligne ; les autorités émettrices vivent dans un domaine d’administration dédié, sans relation d’approbation avec le reste du système d’information.
Le HSM ne suffit pas. Un HSM (Hardware Security Module) garantit que la clé de signature ne sort pas ; il ne garantit pas que la demande de signature est légitime. Un attaquant qui pilote le logiciel d’autorité fait signer ce qu’il veut sans jamais toucher la clé. Il faut un contrôle de la demande en amont (double approbation, quotas d’émission, liste de profils autorisés) et une réconciliation entre les numéros de série signés par le HSM et ceux enregistrés en base.
Journalisation centralisée et protégée. Sans journaux hors d’atteinte de l’attaquant, l’inventaire des certificats émis devient une hypothèse. Les journaux d’émission partent vers un stockage en écriture seule, supervisé par une équipe distincte de celle qui administre l’autorité.
Mises à jour, mots de passe, antivirus. Logiciels non à jour, mots de passe d’administration faibles, antivirus aveugle : rien d’exotique. L’autorité la plus critique du pays tombait sur les erreurs d’un poste de stagiaire, ce qui devrait rassurer les stagiaires et inquiéter tous les autres.
Notification. DigiNotar savait le 19 juillet et s’est tue. Le droit européen a depuis fait de la notification d’incident par un prestataire de services de confiance une obligation (règlement eIDAS n° 910/2014, puis le dispositif NIS 2) ; le délai et le destinataire se lisent dans le texte en vigueur. Les politiques des navigateurs imposent de leur côté une déclaration publique des incidents d’émission.

Côté organisation qui consomme des certificats, la leçon est une condition de reprise : la mort subite de son autorité doit être un incident d’exploitation, pas une crise. Cela suppose un renouvellement automatisé (ACME, Automatic Certificate Management Environment), une seconde autorité déjà identifiée et listée dans l’enregistrement CAA, et un inventaire des certificats à jour. Les clients de DigiNotar ont dû remplacer leurs certificats en urgence, à la main ; c’est ce scénario que la révocation préemptive et l’automatisation rendent banal.

Sources

RFC 6962 : Certificate Transparency, IETF, juin 2013.

Documents de référence

Black Tulip : Report of the investigation into the DigiNotar Certificate Authority breach, Fox-IT, pour le ministère de l’Intérieur et des Relations du Royaume des Pays-Bas, 13 août 2012.
Form 8-K (événement du 19 septembre 2011), VASCO Data Security International, déposé auprès de la Securities and Exchange Commission, 20 septembre 2011.

🐝 Ce qui arrive si on s’en passe

Sans surveillance des journaux CT pour ses propres noms, un certificat émis à tort pour un domaine passe toutes les vérifications des clients et reste invisible pour son propriétaire, qui n’a aucun autre moyen de l’apprendre. Sans enregistrement CAA, le moindre défaut de validation chez n’importe quelle autorité suffit à obtenir un certificat légitime. Sans renouvellement automatisé ni seconde autorité prête, le retrait de confiance d’une racine transforme chaque certificat de l’organisation en panne, à remplacer à la main pendant que les clients voient des erreurs. Et sans magasin de confiance réduit sur les flux internes, un intercepteur muni d’un certificat public valide lit le trafic entre services sans rencontrer un seul contrôle.

🦫 Explication de la marmotte 🍫

Quand on ouvre un site sécurisé, le serveur envoie un certificat : un fichier qui dit « cette clé appartient à google.com », signé par une autorité de certification. Le navigateur contient une liste d’environ cent cinquante autorités qu’il croit, et il accepte toute signature venant de l’une d’elles, pour n’importe quel site. En 2011, un pirate est entré dans les ordinateurs de DigiNotar, une de ces autorités, et lui a fait signer 531 faux certificats, dont un pour Google. Placé sur le réseau iranien, il interceptait les connexions vers Gmail, présentait son faux certificat et lisait les messages au passage. Les navigateurs ordinaires n’ont rien vu, puisque la signature était authentique. Chrome, lui, avait une liste intégrée des seules clés autorisées pour Google ; il a refusé la connexion, et un internaute a signalé l’erreur. DigiNotar savait depuis un mois qu’elle était piratée et n’avait rien dit. Annuler les faux certificats un par un n’a pas fonctionné : l’autorité ne savait même pas tout ce qu’elle avait signé, et les navigateurs ignorent souvent ce contrôle. Les éditeurs ont donc retiré DigiNotar de leur liste par une mise à jour, et l’entreprise a fait faillite. Depuis, tout certificat doit être inscrit dans des registres publics : on ne peut plus en fabriquer en secret, mais il faut que chaque propriétaire de site lise ces registres pour repérer un faux à son nom.

Pages voisines

La citent

Niveaux d'assurance d'authentification : ce qu'il faut pour monter d'un cran

DigiNotar 2011 : compromission d'une autorité de certification

Elle cite

: les deux pages se citent l’une l’autre.