La faille DNS silencieuse qui rendait possibles les faux sites web
Lorsque vous visitez un site web, votre ordinateur ne se connecte pas à un nom comme "example.com". Au lieu de cela, il a besoin d'une IP address. Votre ordinateur envoie une requête à un resolver, généralement votre routeur ou votre FAI, qui consulte ensuite divers serveurs DNS pour trouver la bonne IP address.
Les premières réponses DNS étaient vulnérables car elles reposaient sur un simple identifiant de transaction de 16 bits pour faire correspondre les réponses aux requêtes. Bien que cet identifiant aide à organiser les requêtes, il n'offrait aucune preuve cryptographique de l'identité de l'expéditeur. Les attaquants pouvaient inonder un resolver de réponses forgées, en devinant l'un des 65 536 identifiants possibles, et si une fausse réponse arrivait avant la légitime, le resolver l'acceptait et mettait en cache les données malveillantes.
Cette faille fondamentale est devenue flagrante en 2008 avec la découverte de la Kaminsky attack. Dan Kaminsky a démontré comment exploiter cette faiblesse en ciblant des sous-domaines inexistants arbitraires, permettant aux attaquants d'empoisonner rapidement l'enregistrement du serveur de noms faisant autorité d'un domaine. Cela a exposé le risque généralisé d'empoisonnement du cache DNS et a souligné le besoin urgent d'une architecture DNS plus sécurisée.
La solution à long terme, DNSSEC, avait déjà été formulée en 2005. Elle a introduit l'authentification cryptographique, garantissant que chaque étape de la chaîne de recherche DNS — des serveurs racines aux serveurs de domaine individuels — puisse vérifier l'authenticité de la suivante. Ce système a établi une chaîne de confiance, empêchant les attaquants d'injecter des informations frauduleuses et de rediriger les utilisateurs vers des sites malveillants.
La chaîne de confiance se termine par une clé racine unique
DNSSEC, la solution à long terme aux vulnérabilités DNS, utilise la cryptographie à clé publique pour sécuriser les recherches. Chaque signataire possède une private key pour générer des signatures numériques pour les données DNS et une public key correspondante pour la vérification. Les resolvers utilisent ces public keys pour confirmer que les données DNS n'ont pas été altérées en transit, garantissant leur authenticité.
Une chaîne de confiance s'étend de la racine DNS aux domaines individuels. Lorsqu'un resolver recherche example.com, il interroge d'abord les serveurs racines, qui se portent garants des serveurs de domaine de premier niveau (TLD) .com. Les serveurs .com se portent ensuite garants du propre serveur DNS de example.com. Chaque zone parente signe cryptographiquement les public keys de ses zones enfants, créant un chemin de validation ininterrompu.
La Root Zone Key Signing Key (KSK) est unique ; aucune autorité DNS supérieure n'existe pour l'authentifier. Par conséquent, sa public key doit être préconfigurée en tant que trust anchor dans tous les resolvers validant DNSSEC. Quiconque contrôle la moitié privée de la KSK pourrait signer de fausses données racines, compromettant toute la chaîne de confiance DNS. Cette private key critique est conservée dans un Hardware Security Module hautement sécurisé, isolé physiquement (air-gapped), et n'est accessible que lors de cérémonies de clés multi-parties strictement contrôlées.
À l'intérieur de la cérémonie conçue pour garder une clé secrète
Le maintien du secret de la clé racine nécessite un protocole de sécurité élaboré et multicouche, exécuté dans une installation sécurisée à Culpeper, en Virginie. Ce site, exploité par l'ICANN et Public Technical Identifiers (PTI), protège les Hardware Security Modules (HSMs) qui génèrent et stockent la private key. L'accès à la salle de cérémonie implique plusieurs points de contrôle de sécurité, suivis d'une cage verrouillée, puis de coffres-forts contenant les HSMs eux-mêmes.
Le processus de signature est une mesure de protection multi-personnes. Sept Crypto Officers désignés, issus de la communauté internet mondiale et indépendants de l'ICANN, détiennent chacun une clé de sécurité pour leur coffre-fort individuel. Pour activer le HSM et effectuer une opération protégée, un minimum de trois Crypto Officers doit être physiquement présent et insérer ses clés de sécurité uniques.
Les cérémonies sont observables publiquement et documentées, garantissant la transparence. Les participants démarrent un ordinateur portable à partir d'un système d'exploitation de confiance en lecture seule, en vérifiant son empreinte cryptographique à voix haute. Une fois les trois clés de sécurité insérées, une commande unique lance le processus de génération de clé au sein du HSM isolé (air-gapped). La clé privée ne quitte jamais cet environnement sécurisé, sauf sous forme de sauvegarde chiffrée. L'identifiant de la nouvelle clé, comme 38696 pour la clé de 2024, est ensuite enregistré, et le processus se termine par la signature d'un script papier par tous les participants. Pour plus de détails sur ces procédures, consultez la documentation IANA Root KSK Ceremonies.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Ce qui change lors du renouvellement de la clé racine
Le renouvellement des clés introduit une nouvelle Key Signing Key (KSK), remplaçant l'ancienne en tant que clé de signature active pour l'ensemble d'enregistrements DNSKEY de la zone racine. Bien que la nouvelle clé soit générée et certifiée des mois à l'avance, le « renouvellement » effectif se produit lorsqu'elle devient la clé de signature principale, et sa composante publique doit être disponible pour tous les résolveurs validant DNSSEC en tant qu'ancre de confiance.
L'échec de la mise à jour de cette ancre de confiance peut entraîner des pannes importantes. Un résolveur doté d'une clé publique obsolète sera incapable de valider les signatures générées par la nouvelle KSK, rejetant toutes les réponses DNS pour les domaines signés. Cela entraîne l'affichage d'erreurs SERVFAIL pour les utilisateurs, faisant paraître les sites web inaccessibles même si leurs serveurs sont pleinement opérationnels.
Les résolveurs validant DNSSEC modernes, tels que ceux des FAI ou des services publics comme Cloudflare 1.1.1.1 et Google 8.8.8.8, utilisent généralement des mises à jour automatiques de l'ancre de confiance, atténuant la plupart des risques. Cependant, les anciens micrologiciels de routeurs ou les systèmes configurés manuellement peuvent être à la traîne, nécessitant des mises à jour explicites. Si vous rencontrez des échecs DNS coïncidant avec un renouvellement, la mise à jour du micrologiciel de votre routeur ou du logiciel de votre résolveur est une bonne première étape. N'oubliez pas que la protection DNSSEC dépend à la fois des domaines signés et des résolveurs de validation.
Questions fréquemment posées
Qu'est-ce que la clé maîtresse DNSSEC de l'internet ?
Il s'agit de la partie privée de la Key Signing Key (KSK) de la zone racine, utilisée pour signer les clés DNSSEC de la zone racine. Son homologue public est une ancre de confiance pour les résolveurs de validation.
Pourquoi le DNS a-t-il besoin de DNSSEC ?
DNSSEC ajoute des signatures cryptographiques qui permettent aux résolveurs de validation de vérifier si les données DNS sont authentiques et inchangées, aidant ainsi à empêcher l'acceptation de réponses falsifiées.
Un renouvellement de la clé racine peut-il interrompre ma connexion internet ?
Cela peut perturber le DNS pour les utilisateurs derrière un résolveur de validation qui n'a pas appris la nouvelle ancre de confiance. Le résolveur peut rejeter les réponses, renvoyant souvent une erreur SERVFAIL.
Comment la clé racine est-elle protégée ?
La clé privée est conservée dans du matériel sécurisé, et les opérations sur les clés nécessitent plusieurs participants autorisés. Les cérémonies utilisent des installations contrôlées, des procédures documentées et des registres publics.