Des attaques visant les extensions de domaines .gh, .sl et .as ont permis l’émission de certificats HTTPS non autorisés pour plusieurs domaines de Google et d’autres organisations. Dans une publication du 6 octobre 2026, l’équipe de sécurité de Chrome a expliqué avoir bloqué les certificats identifiés dans son navigateur et collaboré avec les autorités de certification pour obtenir leur révocation.
L’incident rappelle qu’une connexion HTTPS, même chiffrée, ne garantit pas à elle seule que l’internaute communique avec le service légitime attendu. La sécurité du Web dépend également de l’intégrité du système DNS et des mécanismes de validation des certificats.
Des détournements DNS à l’origine de certificats HTTPS non autorisés
Selon le communiqué officiel de Google consacré à la réponse de Chrome, les incidents ont concerné trois extensions de domaines de premier niveau associées à des territoires précis :
- .gh, pour le Ghana ;
- .sl, pour la Sierra Leone ;
- .as, pour les Samoa américaines.
Google indique que les attaquants ont compromis des infrastructures tierces liées à ces espaces de noms, puis modifié des enregistrements DNS faisant autorité. Ces modifications leur ont permis d’obtenir des certificats HTTPS couvrant plusieurs domaines Google ainsi que des domaines appartenant à d’autres organisations.
L’entreprise précise que ses propres systèmes n’ont pas été compromis. Elle indique également ne disposer d’aucun élément permettant de conclure à une faute des autorités de certification ayant émis les certificats concernés.
Comment le détournement a-t-il fonctionné ?
Le DNS, ou système de noms de domaine, permet d’associer un nom lisible — par exemple, celui d’un site Web — aux informations nécessaires pour atteindre le service correspondant. Lorsqu’un attaquant parvient à modifier les enregistrements DNS autoritaires d’un domaine, il peut perturber cette correspondance et influencer la destination vers laquelle les requêtes sont dirigées.
Cette capacité peut aussi être exploitée dans le processus de validation d’un certificat TLS. Pour délivrer un certificat, une autorité de certification doit vérifier que le demandeur contrôle le domaine concerné. Si l’infrastructure DNS utilisée pour cette vérification est compromise, un attaquant peut réussir certaines étapes de validation sans être le propriétaire légitime du domaine.
Dans les incidents décrits par Google, les modifications DNS ont ainsi permis l’obtention de certificats HTTPS non autorisés. Le problème ne résidait donc pas dans une rupture du chiffrement TLS lui-même, mais dans le détournement des mécanismes qui permettent d’associer un certificat à un nom de domaine.
Pourquoi un certificat HTTPS frauduleux représente-t-il un risque ?
Les certificats TLS permettent notamment au navigateur de vérifier l’identité associée à un nom de domaine et d’établir une connexion chiffrée. Lorsqu’un certificat non autorisé est délivré pour un domaine usurpé, cette protection peut être détournée.
Un certificat frauduleux peut faciliter plusieurs scénarios d’attaque, selon les conditions techniques et les possibilités de l’attaquant :
- Usurpation de sites Web : faire passer une infrastructure contrôlée par un attaquant pour un service légitime.
- Hameçonnage : tenter de convaincre les internautes de saisir leurs identifiants ou leurs informations sensibles sur une fausse page.
- Interception de communications : dans certaines configurations, faciliter une attaque de type intermédiaire, notamment si le trafic peut être redirigé vers une infrastructure malveillante.
- Atteinte à la confiance numérique : exploiter le cadenas HTTPS ou l’apparence d’une connexion sécurisée pour tromper les utilisateurs.
L’obtention d’un certificat ne signifie toutefois pas que toutes ces attaques ont effectivement été réalisées. Dans sa publication, Google ne confirme ni un vol de données, ni l’exploitation de chaque certificat à des fins d’interception. L’entreprise ne fournit pas non plus une liste exhaustive des organisations concernées.
Cet incident illustre néanmoins une limite importante : HTTPS chiffre la communication, mais ne peut pas compenser à lui seul une compromission de l’infrastructure qui permet de valider l’identité du domaine.
Google bloque les certificats identifiés dans Chrome
Pour limiter les risques, Google a indiqué avoir pris des mesures immédiates après la découverte des détournements. Chrome a bloqué les certificats non autorisés identifiés pour les services Google au moyen des CRLSets, un mécanisme permettant au navigateur de rejeter certains certificats révoqués ou considérés comme dangereux.
Google a également travaillé avec les autorités de certification émettrices afin d’obtenir la révocation des certificats concernés. Cette étape est importante, car le blocage effectué par Chrome ne suffit pas à protéger automatiquement les utilisateurs d’autres navigateurs ou applications.
L’analyse des journaux de Certificate Transparency a ensuite révélé des indices d’exposition concernant d’autres organisations, notamment des marques internationales et des services en ligne largement utilisés. Google a étendu ses mesures de blocage aux certificats supplémentaires identifiés et indique avoir alerté les organisations concernées lorsque cela était possible.
Les utilisateurs doivent-ils effectuer une action particulière ?
Selon Google, les utilisateurs de Chrome n’ont aucune action spécifique à effectuer pour bénéficier des blocages annoncés.
Cette mesure ne constitue toutefois pas une garantie de protection absolue. L’entreprise reconnaît ne pas pouvoir assurer que tous les domaines touchés ont été identifiés. En outre, les interventions réalisées dans Chrome ne protègent pas systématiquement les personnes utilisant d’autres navigateurs ou des applications qui s’appuient sur leurs propres mécanismes de validation.
Les utilisateurs doivent donc maintenir leurs logiciels à jour et éviter de contourner les avertissements de sécurité relatifs aux certificats. Si un navigateur signale un problème de connexion, il est préférable de quitter la page plutôt que de forcer l’accès.
Les propriétaires de domaines doivent surveiller les journaux Certificate Transparency
Google recommande aux organisations de mettre en place une surveillance continue des journaux de Certificate Transparency (CT). Ces journaux publics enregistrent les certificats TLS émis par les autorités de certification participantes et permettent de repérer plus rapidement les émissions inattendues.
La surveillance doit couvrir l’ensemble du portefeuille de domaines, et pas uniquement le site principal de l’organisation. Les domaines régionaux, secondaires, inutilisés ou réservés peuvent également présenter un risque s’ils sont négligés.
Pour les entreprises disposant de domaines en .gh, .sl ou .as, il est particulièrement important d’examiner les certificats récemment enregistrés et de vérifier qu’ils correspondent à des demandes légitimes.
Une procédure de surveillance efficace doit notamment permettre de :
- détecter les nouveaux certificats émis pour les domaines de l’organisation ;
- comparer les certificats observés avec les autorités et les prestataires autorisés ;
- identifier les certificats inattendus ou les noms de domaine inhabituels ;
- déclencher une investigation lorsqu’une émission suspecte est repérée ;
- révoquer les certificats non autorisés et vérifier que les mesures correctives ont été appliquées.
Les équipes de sécurité peuvent consulter les recommandations de Google dans son article officiel sur les détournements de registres de domaines.
Les enregistrements CAA : une protection complémentaire à renforcer
Google recommande également aux propriétaires de domaines de publier des enregistrements DNS CAA (Certification Authority Authorization). Ces enregistrements permettent d’indiquer quelles autorités de certification sont autorisées à délivrer des certificats pour un domaine.
Une politique CAA restrictive réduit les possibilités d’émission par des autorités non autorisées. Lorsque les mécanismes techniques le permettent, les organisations peuvent renforcer cette politique en limitant également les comptes ACME et les méthodes de validation acceptés.
Il faut cependant comprendre la limite de cette mesure : un enregistrement CAA ne bloque pas nécessairement l’émission d’un certificat pendant un détournement DNS actif. Un attaquant qui contrôle les enregistrements concernés peut être en mesure de les modifier ou de contourner temporairement la politique prévue.
La configuration CAA devient particulièrement importante après la reprise de contrôle du DNS. En effet, certaines autorités de certification peuvent réutiliser pendant une période donnée une validation de contrôle de domaine précédemment effectuée. Une politique restrictive correctement restaurée peut alors empêcher de nouvelles émissions non autorisées reposant sur un état de validation encore considéré comme valable.
Les organisations doivent donc associer les enregistrements CAA à d’autres mesures : sécurisation des accès au fournisseur DNS, contrôle des modifications, authentification multifacteur sur les comptes d’administration et procédure d’intervention en cas de compromission.
Quelles mesures de sécurité les organisations doivent-elles prendre ?
Au-delà des recommandations spécifiques de Google, plusieurs mesures opérationnelles peuvent contribuer à limiter les conséquences d’un détournement DNS.
1. Vérifier les accès à la gestion des domaines
Les comptes utilisés pour administrer les domaines, les registres et les services DNS doivent être protégés par une authentification multifacteur lorsque celle-ci est disponible. Les droits d’administration doivent être limités aux personnes qui en ont réellement besoin.
Les organisations doivent également examiner les journaux d’audit et mettre en place des alertes en cas de modification inhabituelle des serveurs de noms ou des enregistrements DNS.
2. Contrôler régulièrement les certificats émis
Une liste à jour des domaines, sous-domaines et certificats légitimes facilite la détection des anomalies. La surveillance des journaux CT doit être intégrée aux procédures de gestion des incidents afin que les équipes puissent réagir rapidement à une émission inattendue.
3. Préparer une procédure de réponse à incident
En cas de détournement DNS, les équipes doivent pouvoir vérifier l’intégrité des enregistrements, reprendre le contrôle des accès, contacter le prestataire concerné et demander la révocation des certificats non autorisés.
Une fois le contrôle rétabli, il est nécessaire de vérifier les politiques CAA, les méthodes de validation et les éventuelles demandes de certificats encore en cours.
4. Informer les utilisateurs sans créer de confusion
Si un domaine est susceptible d’avoir été affecté, l’organisation doit communiquer par des canaux fiables et distincts du domaine potentiellement compromis. Les utilisateurs doivent être informés des éventuelles précautions à prendre et des services officiellement concernés, sans affirmer qu’il y a eu vol de données si aucun élément ne le démontre.
Conclusion : la sécurité HTTPS dépend aussi de la confiance accordée au DNS
Les détournements touchant les extensions .gh, .sl et .as montrent que la sécurité du Web dépend d’une chaîne de confiance plus large que le seul chiffrement HTTPS. Une compromission des infrastructures DNS peut permettre d’obtenir des certificats non autorisés et de fragiliser les mécanismes censés vérifier l’identité des sites.
Google a bloqué dans Chrome les certificats qu’il a identifiés et collaboré avec les autorités de certification pour obtenir leur révocation. Mais l’entreprise reconnaît que ces mesures ne garantissent pas la détection de tous les domaines affectés et ne couvrent pas systématiquement les autres navigateurs.
Pour les organisations, les priorités sont claires : sécuriser l’administration des domaines, surveiller les journaux Certificate Transparency, appliquer une politique CAA restrictive et préparer une réponse rapide aux incidents. Pour les utilisateurs, la vigilance reste essentielle : un cadenas HTTPS ne doit jamais être considéré comme une garantie absolue de légitimité.
La protection durable du Web repose ainsi sur plusieurs mécanismes complémentaires, une surveillance continue et une coopération efficace entre les propriétaires de domaines, les autorités de certification et les éditeurs de navigateurs.
SOURCES :
