Certificats HTTPS pour Google : trois registres piratés ont suffi

L’alerte vient de l’équipe de sécurité de Chrome, dans un billet publié le 6 octobre. La semaine précédente, Google a eu connaissance d’une « série de détournements de domaines » dans trois extensions nationales : .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). Pendant ces détournements, écrit l’entreprise, les attaquants ont « modifié des enregistrements DNS faisant autorité » et obtenu des certificats HTTPS non autorisés « couvrant plusieurs domaines de Google, ainsi que des domaines appartenant à d’autres organisations ».

Google insiste sur deux points. Ses propres systèmes n’ont pas été compromis : ce sont les registres, gérés par des tiers, qui l’ont été, ce qui mettait en danger « tout domaine se terminant par .gh, .sl ou .as ». Et il n’a « aucune raison de penser » que les autorités de certification qui ont délivré ces certificats aient « fait quoi que ce soit de mal ». Des certificats authentiques, émis, selon Google, dans les règles, au profit d’attaquants : tout tient à la façon dont internet décide qui possède un nom.

Du registre au cadenas, quatre maillons

Le registre. Chaque extension (.fr, .com, .gh…) est gérée par un registre. Il tient la liste des noms enregistrés et indique, pour chacun, quels serveurs DNS font autorité. Le DNS (Domain Name System) est l’annuaire d’internet, qui traduit un nom en adresse de machine.

Le DNS faisant autorité. Ces serveurs donnent la réponse officielle pour un domaine : l’adresse du site, celle des serveurs de messagerie, etc. Qui modifie, chez le registre, la liste des serveurs d’un domaine peut y substituer les siens et répondre ce qu’il veut pour ce nom.

La validation de domaine. Avant de délivrer un certificat, le fichier qui permet au navigateur d’afficher le cadenas et d’établir une connexion chiffrée, une autorité de certification (AC) vérifie que le demandeur contrôle bien le nom. Chez Let’s Encrypt, par exemple, il doit déposer un fichier à une adresse précise du site (défi « HTTP-01 ») ou publier un enregistrement TXT dans le DNS du domaine (défi « DNS-01 »). Google présentait en décembre 2025 cette étape comme un processus « critique pour la sécurité », et l’industrie est en train d’abandonner les méthodes plus anciennes, par courriel ou téléphone, au profit de ces défis techniques.

Le certificat. Si le défi est relevé, l’AC signe.

Le problème apparaît : ces défis reposent sur le DNS. Un attaquant qui contrôle le DNS faisant autorité fait pointer le nom vers son propre serveur, ou publie lui-même l’enregistrement demandé. L’AC constate que le défi est relevé et délivre le certificat, conformément aux règles. Google ne précise pas quelle méthode de validation a été utilisée. Il situe le risque dans les trois extensions compromises, ce qui est logique puisqu’un registre ne gère que les noms de la sienne, mais ne dit pas lesquels de ses domaines ont été visés, par exemple ses déclinaisons nationales.

Un vrai cadenas sur un faux site

Le certificat ne fait pas le piratage, il le rend invisible. Quelqu’un qui contrôle le DNS d’un domaine peut déjà diriger les visiteurs vers son serveur, mais sans certificat valide le navigateur afficherait une alerte. Avec, le faux site présente le cadenas habituel.

Google ne dit rien d’un usage réel de ces certificats. Le scénario n’a pourtant rien de théorique. En avril 2019, les chercheurs de Cisco Talos décrivaient la campagne « Sea Turtle » : au moins 40 organisations touchées dans 13 pays entre janvier 2017 et le premier trimestre 2019, avec des bureaux d’enregistrement et un registre parmi les victimes intermédiaires. L’enchaînement était le même : modifier les serveurs de noms d’un domaine, obtenir des certificats signés par des AC reconnues (Let’s Encrypt, Comodo, Sectigo selon Talos), intercepter le trafic, récolter des identifiants, y compris d’accès à des réseaux privés d’entreprise (VPN).

La riposte de Chrome : une liste noire d’urgence

Chrome ne vérifie en général pas en ligne si un certificat a été révoqué, explique la documentation de Chromium. Il s’appuie sur les CRLSets, une liste de certificats bloqués que Google met à jour à distance et qui constitue « le principal moyen » pour le navigateur de bloquer rapidement des certificats « en situation d’urgence ». Google dit avoir agi « immédiatement », dans le cadre de sa procédure habituelle de réponse aux incidents, pour bloquer par ce biais les certificats visant ses domaines.

Cette liste ne protège que Chrome. Google indique donc avoir travaillé avec les AC émettrices pour que ces certificats soient révoqués, afin de protéger les utilisateurs des « clients autres que Chrome » : autres navigateurs, applications, logiciels qui vérifient les certificats. Les utilisateurs de Chrome n’ont, selon Google, rien à faire.

L’entreprise tempère aussitôt elle-même cette assurance : les propriétaires de sites ne doivent pas compter sur l’intervention du navigateur pour protéger leurs utilisateurs. Vu la complexité des détournements DNS, Google « ne peut pas garantir » que son analyse a repéré tous les domaines touchés, et les mesures prises dans Chrome ne protègent pas de façon fiable les utilisateurs d’autres logiciels.

La transparence des certificats a révélé d’autres victimes

Après cette première riposte, les journaux de transparence des certificats (Certificate Transparency, CT) ont révélé, selon Google, d’autres organisations qui auraient été touchées par les mêmes attaques, dont « plusieurs grandes marques mondiales et services en ligne très utilisés ». Google a bloqué leurs certificats dans Chrome de façon préventive et dit avoir alerté les organisations concernées « lorsque c’était possible ».

Ces journaux sont des registres publics, en ajout seul : on peut y ajouter un certificat, jamais en effacer, et n’importe qui peut les consulter. Les AC y inscrivent les certificats qu’elles délivrent, et Chrome comme Safari exigent qu’un certificat porte au moins deux preuves d’inscription, leur nombre dépendant de sa durée de validité. Google le rappelle dans son billet : tout certificat reconnu par défaut sur lequel s’appuie Chrome « doit être publié » dans ces journaux. Conséquence : un certificat frauduleux qui doit fonctionner dans Chrome ne peut pas rester secret. L’attaquant obtient son cadenas, mais il laisse une trace publique que tout le monde peut lire, Google compris. L’entreprise ne dit pas combien d’organisations elle a ainsi repérées, ni lesquelles.

Ce que peuvent faire les gestionnaires de domaines

Les propriétaires de domaines sont, écrit Google, « les mieux placés » pour savoir quels certificats et quelles AC sont autorisés pour leurs noms. D’où ses recommandations, que d’autres sources complètent.

Surveiller les journaux. Pour Google, cette surveillance fournit une alerte « quasi en temps réel » chaque fois qu’un certificat est délivré pour l’un de vos domaines. Il recommande de couvrir tout le portefeuille de noms, « y compris les domaines parqués ou régionaux » sous extension nationale. Le projet CT recense des services de surveillance, dont Cloudflare, qui envoie un courriel à chaque émission, ou le moteur de recherche crt.sh. À ceux qui exploitent un domaine en .gh, .sl ou .as, Google conseille d’examiner les inscriptions récentes à la recherche d’émissions inattendues.

Publier des enregistrements CAA. Un enregistrement CAA (Certification Authority Authorization), défini par la RFC 8659, est une ligne du DNS qui désigne les AC autorisées à émettre pour un domaine ; une AC conforme doit la consulter avant chaque émission. La RFC 8657 permet d’aller plus loin : restreindre l’émission à un compte précis chez l’AC (paramètre accounturi) et à certaines méthodes de validation (validationmethods). Let’s Encrypt reconnaît ces deux paramètres.

Connaître la limite de CAA. Un enregistrement CAA est stocké dans le DNS, celui-là même que l’attaquant contrôle pendant un détournement : il peut le supprimer ou le réécrire. La RFC 8659 le reconnaît dans ses considérations de sécurité, et Google l’écrit sans détour : CAA « ne peut pas empêcher l’émission de certificats pendant un détournement DNS actif ». Il peut en revanche, selon Google, « empêcher entièrement certaines attaques » qui passent par le routage du trafic ou par le serveur web, c’est-à-dire, en général, quand l’attaquant n’a pas la main sur le DNS. Et son intérêt principal, dans une affaire comme celle-ci, se situe après. Les règles permettent aux AC de conserver et de réutiliser une validation de domaine déjà effectuée pour des émissions ultérieures. Un attaquant qui a validé un domaine pendant le détournement pourrait donc obtenir de nouveaux certificats une fois le DNS rendu à son propriétaire. Rétablir une politique CAA restrictive, surtout liée à un compte et à une méthode, empêche selon Google cette réutilisation. La durée pendant laquelle une validation peut servir doit elle-même diminuer : le CA/Browser Forum, qui réunit AC et éditeurs de navigateurs, a voté en avril 2025 sa réduction progressive de 398 jours à 10 jours, avec un calendrier qui s’achève en mars 2029. Google dit vouloir continuer à réduire la durée de validité des certificats et celle de la réutilisation des validations, par les règles qu’il impose aux AC reconnues par Chrome.

Verrouiller en amont. En 2019, Talos recommandait l’authentification à plusieurs facteurs pour l’accès à la gestion DNS et le « verrou de registre », qui impose une confirmation par un canal séparé avant toute modification. Ce verrou est appliqué par le registre lui-même : face à un registre compromis, comme dans l’affaire actuelle, rien ne garantit qu’il tienne.

Ce qui reste dans l’ombre

Le billet de Google laisse de nombreuses questions ouvertes. Il ne nomme ni les grandes marques et services visés, ni les AC émettrices, ni le nombre de certificats. Google admet lui-même ne pas pouvoir garantir que tous les domaines touchés ont été repérés : d’autres certificats frauduleux pourraient exister sans être bloqués. Pour les organisations repérées ensuite grâce aux journaux CT, le billet ne mentionne que le blocage dans Chrome ; il ne précise pas si leurs certificats ont aussi été révoqués, ce qui protégerait les autres navigateurs et applications. Il n’explique pas comment les registres ont été compromis, ni combien de temps les détournements ont duré, ni si la situation est rétablie. Nous n’avons trouvé aucune communication des registres du Ghana, de la Sierra Leone ou des Samoa américaines au 7 octobre.

Ce qui est établi suffit pourtant à tirer une leçon : la sécurité du cadenas ne vaut que ce que vaut le DNS du domaine, et celui-ci dépend d’un registre que le propriétaire du nom ne contrôle pas. La transparence des certificats ne prévient pas l’émission frauduleuse ; elle permet de la voir vite, à condition que quelqu’un regarde.

Les citations de documents en anglais sont traduites par la rédaction.