Le cadenas était valide, le site était faux : les détournements des registres .gh, .sl et .as expliqués

Le 6 octobre 2026, l’équipe de sécurité de Chrome chez Google a publié un court billet au titre sec et au contenu alarmant : des attaquants avaient pris le contrôle de trois registres de domaines nationaux, le .gh du Ghana, le .sl de la Sierra Leone et le .as des Samoa américaines, modifié des enregistrements DNS faisant autorité et obtenu des certificats HTTPS valides pour des domaines Google et pour « plusieurs grandes marques mondiales » qu’il n’a pas nommées. Quiconque aurait atterri sur l’un des faux sites aurait vu un cadenas de navigateur sans rien d’anormal.

L’incident vaut la peine d’être compris correctement, car il se situe au point exact où le modèle mental que la plupart des gens ont de la sécurité du web est faux. Le cadenas ne veut pas dire « ceci est le vrai site ». Il veut dire quelque chose de bien plus étroit, et fin septembre, l’écart entre les deux est devenu une attaque opérationnelle.

Une définition porte toute cette page : un certificat à validation de domaine prouve une seule chose, qu’au moment de son émission le demandeur contrôlait le DNS du domaine. Quand le registre au-dessus du DNS est volé, le voleur est, pour chaque vérification automatisée au monde, le propriétaire.

Qu'est-il arrivé aux .gh, .sl et .as ?

Un registre national est l’organisation qui gère la base de données maîtresse de tout ce qui vit sous son domaine à deux lettres : le .gh est opéré par Network Computer Systems à Accra, le .sl par l’opérateur télécom Sierratel, le .as par l’AS Domain Registry. Compromettez cette base et vous n’avez plus besoin de pirater le moindre site, puisque vous pouvez redéléguer n’importe quel nom sous le TLD vers des serveurs que vous contrôlez.

C’est ce qui s’est produit, un registre à la fois. Des certificats sont apparus dans les journaux publics pour des noms en .gh le 22 septembre, en .sl le 25 septembre et en .as le 27 septembre, ce qui se lit comme une équipe qui descend une liste. Google dit que les attaquants ont « modifié des enregistrements DNS faisant autorité et obtenu des certificats HTTPS non autorisés couvrant plusieurs domaines Google, ainsi que des domaines appartenant à d’autres organisations », et que ses propres systèmes n’ont pas été touchés.

Une quantité remarquable de choses reste non divulguée : comment les registres ont été percés, qui l’a fait, si un certificat a été utilisé contre de vrais utilisateurs, et la liste complète des victimes. Aucun des trois opérateurs de registre n’avait publié de communiqué au moment où nous écrivons. Nous disons « non divulgué » là où c’est l’état des choses, et chaque article que vous lisez devrait faire de même.

Comment des attaquants ont-ils obtenu des certificats valides pour des domaines Google ?

En les demandant poliment. The Hacker News, en travaillant sur le registre public de Certificate Transparency, a compté au moins 12 certificats couvrant 7 domaines Google et YouTube, google.com.gh, google.sl, google.as et leurs variantes parmi eux : 11 émis par Let’s Encrypt et 1 par ZeroSSL, tous à validation de domaine. Un membre de l’équipe de Let’s Encrypt a confirmé l’émission et les révocations sur le forum du projet.

Voici la partie inconfortable : les autorités de certification ont suivi leurs règles. Google lui-même a écrit n’avoir « aucune raison de croire que les autorités de certification (AC) qui ont émis les certificats concernés aient fait quoi que ce soit de mal ». La validation de domaine demande au demandeur de prouver le contrôle du DNS du domaine, typiquement en publiant un enregistrement. Les attaquants étaient le DNS. Chaque vérification automatisée qu’ils ont affrontée, ils l’ont passée honnêtement, au sens étroit où les machines comprennent l’honnêteté.

Un détail montre à quoi ressemble la vigilance à cette couche : dans les enregistrements journalisés consultés, en remontant au moins au 10 septembre, tous les autres certificats pour google.com.gh, google.sl et google.as venaient de Google Trust Services, l’AC de Google lui-même. Douze certificats issus de deux AC sans lien avec Google étaient en soi l’anomalie, posée dans un journal public, attendant que quelqu’un regarde.

Qui a détecté l'attaque, et comment a-t-elle été stoppée ?

Trois mécanismes, par ordre de vitesse.

D’abord, Certificate Transparency a rendu les certificats visibles tout court. Depuis le 30 avril 2018, Chrome rejette tout certificat non divulgué dans les journaux CT publics, si bien qu’un attaquant qui veut un certificat fonctionnant dans le navigateur le plus utilisé du monde doit aussi remettre au monde un aveu signé de son existence. Le compteur public de l’écosystème dépasse 2,5 milliards de certificats consignés, et Let’s Encrypt a franchi à lui seul les dix millions de certificats émis en une seule journée fin septembre 2025 ; trouver 12 mauvais certificats dans cette botte de foin est exactement ce pour quoi l’infrastructure de journaux existe.

Ensuite, Chrome a bloqué les certificats via les CRLSets, sa liste de blocage d’urgence, qui voyage par le composant de mise à jour du navigateur et prend effet sans mise à jour ni redémarrage. L’équipe de sécurité de Chrome soutient depuis des années que les vérifications de révocation en ligne échouent exactement quand on en a besoin, puisque l’attaquant au milieu peut bloquer la vérification elle-même ; la liste de blocage voyage avec le navigateur à la place. Google a ensuite fouillé les données CT à la recherche d’autres victimes, bloqué ces certificats aussi, et dit avoir contacté les organisations concernées quand il le pouvait.

Enfin, la voie lente qui couvre tous les autres : les AC ont révoqué les 12 certificats, les deux certificats .gh et l’unique certificat ZeroSSL le 26 septembre, les neuf autres le 1er octobre. La fenêtre la plus courte entre l’apparition d’un certificat dans le journal et sa mort a été d’environ un jour et demi ; la plus longue, de près d’une semaine. La clause d’honnêteté de Google mérite citation : « nous ne pouvons pas garantir que notre analyse a identifié chaque domaine affecté, et les interventions de Chrome ne protègent pas de manière fiable les utilisateurs d’autres navigateurs ».

DNSSEC ou les enregistrements CAA auraient-ils empêché ces détournements ?

Cet incident est la démonstration la plus propre depuis des années de ce que ces deux sigles achètent, et de ce qu’ils n’achètent pas.

DNSSEC d’abord. En vérifiant la zone racine publiée : .gh et .sl ne sont pas signés du tout, ce qui les place parmi les nombreux ccTLD qui n’ont jamais déployé DNSSEC, une technologie adoptée par 99 % des registres en Europe mais 65 % en Afrique. Et .as est signé, et a été détourné quand même. DNSSEC permet à un résolveur de vérifier qu’une réponse correspond à ce que le registre a publié. Quand le registre lui-même est hostile, il publie les données de l’attaquant, clés comprises. La signature au bas d’un mensonge reste une signature valide.

Les enregistrements CAA, qui laissent un propriétaire de domaine déclarer quelles AC peuvent émettre pour lui, ont une forme plus subtile. Pendant le détournement, ils ne servent à rien, car l’enregistrement CAA vit dans le DNS même que l’attaquant contrôle ; le standard CAA lui-même concède qu’un attaquant capable d’éditer le DNS peut retirer l’enregistrement. Après le détournement, ils comptent énormément, car les AC peuvent réutiliser une validation réussie jusqu’à 200 jours selon les règles actuelles du CA/Browser Forum, une fenêtre qui tombe à 100 jours en mars 2027 et à 10 jours en 2029, si bien qu’un attaquant qui a perdu le DNS pourrait encore frapper des certificats frais à partir de vérifications en cache. Au 7 octobre, les sept domaines Google victimes connus portaient tous des enregistrements CAA ne nommant que l’AC de Google lui-même. C’est la serrure qu’on pose après ce cambriolage précis, et c’est une vraie serrure.

Est-ce déjà arrivé ?

Les attaques contre les registres et l’infrastructure DNS sont un genre, pas une nouveauté. Le dossier daté :

Il existe 316 TLD nationaux parmi les quelque 1 400 domaines de la zone racine, chacun lié à un pays ou à un territoire, chacun avec son budget, sa gouvernance et sa posture de sécurité, certains gérés par des opérateurs privés. L’autorité statutaire du Ghana pour les domaines a elle-même passé des années dans un différend public sur qui devrait seulement opérer le .gh. Le modèle de confiance du web repose, en partie, sur l’idée que la moins financée de ces organisations dispose d’une bonne équipe de sécurité.

Qu'auriez-vous vu, et qu'est-ce qui vous protège vraiment ?

Si vous aviez été routé vers l’un des faux sites pendant la fenêtre, vous n’auriez rien vu. Un certificat valide, un cadenas normal, aucun avertissement d’aucune sorte ; comme l’a écrit Ars Technica, la possession de tels certificats « permet aux attaquants d’usurper cryptographiquement l’infrastructure affectée ». Savoir si quelqu’un a réellement été routé vers ces sites fait partie des faits non divulgués.

Ce qui a protégé les utilisateurs n’est rien de ce qu’un utilisateur a fait. La piste écrite obligatoire de CT a exposé les certificats, les CRLSets les ont tués dans Chrome sans la moindre action requise, et la révocation a couvert le reste. Une couche de plus mérite mention : les applications natives qui épinglent leurs clés. Dans l’affaire togolaise de 2017, l’épinglage de Chrome aurait de toute façon rejeté le certificat google.tg frauduleux, et les applications de Google comme beaucoup d’applications bancaires épinglent encore aujourd’hui. La défense en profondeur n’est pas un slogan ici ; c’est une pile précise, et fin septembre, chaque couche de cette pile portait du poids.

Un VPN protège-t-il contre cette attaque ?

Une page de sécurité honnête répond à cette question avec précision, alors voici la réponse précise : non pour cette classe d’attaque, oui pour ses cousines plus courantes, et savoir laquelle est laquelle est tout le jeu.

Un VPN ne participe pas à TLS. Votre navigateur valide les certificats contre son magasin de confiance de manière identique sur n’importe quel réseau, et ces certificats étaient valides. Pire pour tout outil en aval du DNS : les attaquants ont empoisonné les enregistrements faisant autorité au registre, si bien que chaque résolveur honnête de la planète, ceux d’un fournisseur de VPN compris, servait les réponses de l’attaquant. Aucun VPN, le nôtre compris, n’aurait bloqué cela. Ce qui l’a stoppé, c’est le pipeline CT, CRLSets et révocation décrit plus haut.

Ce qu’un VPN défend, c’est votre côté de la connexion. Sur un réseau local hostile, un point d’accès piégé ou un FAI qui altère le trafic, l’attaquant se tient entre votre appareil et l’internet, injectant des réponses DNS ou redirigeant le trafic. Un VPN déplace votre résolution DNS et le chemin de votre trafic dans un tunnel chiffré qui, comme le dit le guide de l’EFF, cache votre trafic à « votre FAI et au propriétaire du réseau local (comme un café ou un hôtel) ». C’est la surface d’attaque courante, celle du quotidien, celle que nous couvrons dans nos guides sur le chiffrement VPN et la sécurité sur le Wi-Fi public, et c’est précisément la couche que les attaquants des registres n’ont jamais eu besoin de toucher. Les deux protections sont complémentaires, pas interchangeables, et c’est aussi pourquoi nous maintenons une page honnête distincte sur ce que les sites voient encore quand le VPN est activé.

Que doivent faire les propriétaires de domaines maintenant ?

Le conseil de Google aux organisations tient en deux gestes, et il vaut autant pour une entreprise à trois domaines que pour une à trois mille. Surveillez les journaux de Certificate Transparency pour chaque domaine que vous détenez, domaines garés et régionaux compris ; les 12 certificats frauduleux sont restés des jours dans des journaux publics, visibles de quiconque regardait. Et publiez des enregistrements CAA restrictifs nommant votre AC, idéalement avec la liaison de compte ACME, pour que même votre propre AC n’émette que vers votre compte. Le règlement des AC ajoute un troisième geste : si un certificat non demandé apparaît, déposez un Certificate Problem Report, que les Baseline Requirements du secteur obligent l’AC à instruire, avec de premières conclusions sous 24 heures.

Pour tous les autres, les leçons sont plus petites mais réelles. Gardez votre navigateur à jour, car la liste de blocage qui a sauvé les utilisateurs de Chrome voyage avec lui. Traitez le cadenas pour ce qu’il est, une déclaration sur le chiffrement en transit, pas sur qui se trouve à l’autre bout. Et placez chaque outil à sa propre couche : le système de certificats authentifie les sites, un VPN protège le chemin que prend votre trafic, et l’incident de septembre exigeait que le premier échoue proprement pendant que le second n’était jamais en jeu.