Comment fonctionne DNSSEC
Le système de noms de domaine (DNS, Domain Name System) est l'annuaire téléphonique du web : il indique aux ordinateurs où envoyer et récupérer des informations. Malheureusement, il accepte également toute adresse qui lui est donnée, sans poser de questions.
Les serveurs de messagerie utilisent le DNS pour acheminer leurs messages, ce qui signifie qu’ils sont vulnérables aux problèmes de sécurité de l’infrastructure DNS. En septembre 2014, des chercheurs de l’établissement Carnegy Mellon University ont découvert que des e-mails supposés être acheminés par les serveurs de Yahoo!, Hotmail et Gmail transitaient par des serveurs de messagerie non autorisés. Les pirates informatiques exploitaient une vulnérabilité du système de noms de domaine (DNS) vieille de plusieurs décennies : ce système ne vérifie pas les informations d’identification avant d’accepter une réponse.
La solution est un protocole nommé DNSSEC, qui ajoute une couche de confiance au DNS en assurant l’authentification Lorsqu’un résolveur DNS recherche blog.cloudflare.com, les serveurs de noms .com aident le résolveur à vérifier les enregistrements renvoyés pour Cloudflare, et Cloudflare aide à vérifier les enregistrements renvoyés pour le blog. Les serveurs de noms DNS racines aident à vérifier .com, et les informations publiées par la racine sont vérifiées par une procédure de sécurité approfondie qui inclut le processus Root Signing Ceremony.
Petite introduction à DNSSEC
DNSSEC crée un système de noms de domaine sécurisé en ajoutant des signatures cryptographiques aux enregistrements DNS existants. Ces signatures numériques sont stockées dans des serveurs de noms DNS parallèlement à des types d'enregistrement courants comme A, AAAA, MX, CNAME, etc. En vérifiant sa signature associée, vous pouvez vérifier qu'un enregistrement DNS demandé provient de son serveur de noms faisant autorité et qu'il n'a pas été modifié en chemin, contrairement à un faux enregistrement injecté dans une attaque de l'homme du milieu.
Pour faciliter la validation des signatures, DNSSEC ajoute quelques nouveaux types d'enregistrements DNS :
- RRSIG : contient une signature cryptographique
- DNSKEY : contient une clé de signature publique
- DS : contient le hachage d'un enregistrement DNSKEY
- NSEC et NSEC3 : pour le déni d'existence explicite d'un enregistrement DNS
- CDNSKEY et CDS : pour une zone fille demandant des mises à jour d'un ou de plusieurs enregistrements DS dans la zone parent.
Dans cet article, nous allons aborder l'interaction entre les enregistrements RRSIG, DNSKEY et DS, ainsi que la façon dont ils ajoutent une couche de confiance en haut du DNS.
RRsets
La première étape pour sécuriser une zone avec DNSSEC consiste à regrouper tous les enregistrements de même type dans un ensemble d'enregistrements de ressources (RRset). Par exemple, si trois enregistrements AAAA dans votre zone ont la même étiquette (c'est-à-dire label.example.com), ils seront tous regroupés en un seul RRset AAAA.
C'est en fait ce RRset complet qui est signé numériquement, contrairement aux enregistrements DNS individuels. Bien sûr, cela signifie également que vous devez demander et valider tous les enregistrements AAAA d'une zone portant la même étiquette au lieu de ne valider qu'un seul d'entre eux.
Clés de signature de zone
Chaque zone dans le DNSSEC possède une paire de clés de signature de zone (ZSK) : la partie privée de la clé signe numériquement chaque RRset de la zone, tandis que la partie publique vérifie la signature. Pour activer DNSSEC, un opérateur de zone crée des signatures numériques pour chaque RRset à l'aide de la ZSK privée et les stocke dans son serveur de noms en tant qu'enregistrements RRSIG. Cela revient à dire « Ce sont mes enregistrements DNS, ils proviennent de mon serveur et ils devraient ressembler à ça ».
Cependant, ces enregistrements RRSIG sont inutiles à moins que les résolveurs DNS puissent vérifier les signatures. L'opérateur de la zone doit également rendre sa ZSK publique disponible en l'ajoutant à son serveur de noms dans un enregistrement DNSKEY.
Lorsqu'un résolveur DNSSEC demande un type d'enregistrement particulier (par exemple, AAAA), le serveur de noms renvoie également le RRSIG correspondant. Le résolveur peut alors extraire du serveur de noms l'enregistrement DNSKEY contenant la ZSK publique. Ensemble, le RRset, le RRSIG et la ZSK publique peuvent valider la réponse.
Si nous faisons confiance à la clé de signature de zone dans l'enregistrement DNSKEY, nous pouvons faire confiance à tous les enregistrements de la zone. Mais qu'en est-il si la clé de signature de zone est compromise ? Nous devons trouver un moyen de valider la ZSK publique.
Clés de signature de clé
En plus d'une clé de signature de zone, les serveurs de noms DNSSEC disposent également d'une clé de signature de clés (KSK). La KSK valide l'enregistrement DNSKEY exactement de la même manière que notre ZSK a sécurisé le reste de nos RRsets dans la section précédente : elle signe la ZSK publique (qui est stockée dans un enregistrement DNSKEY), créant ainsi un RRSIG pour le DNSKEY.
Tout comme la ZSK publique, le serveur de noms publie la KSK publique dans un autre enregistrement DNSKEY, ce qui nous donne le RRset DNSKEY indiqué ci-dessus. La KSK publique et la ZSK publique sont toutes deux signées par la KSK privée. Les résolveurs peuvent ensuite utiliser la KSK publique pour valider la ZSK publique.
Pour les résolveurs, la validation ressemble maintenant à ce qui suit :
- Demande du RRset souhaité, qui renvoie également l'enregistrement RRSIG correspondant.
- Demande des enregistrements DNSKEY contenant la ZSK publique et la KSK publique, qui renvoient également le RRSIG pour le RRset DNSKEY.
- Vérification du RRSIG du RRset demandé à l'aide de la ZSK publique.
- Vérification du RRSIG du RRset DNSKEY à l'aide de la KSK publique.
Bien entendu, le RRset DNSKEY et les enregistrements RRSIG correspondants peuvent être mis en cache, ainsi les serveurs de noms DNS ne sont pas constamment bombardés de requêtes inutiles.
Pourquoi utilisons-nous des clés de signature de zone et des clés de signature de clé distinctes ? Comme nous le verrons dans la section suivante, il est difficile de remplacer une KSK obsolète ou compromise. Changer la ZSK, en revanche, est beaucoup plus facile. Nous pouvons ainsi utiliser une ZSK plus petite sans compromettre la sécurité du serveur, en réduisant la quantité de données que le serveur doit envoyer avec chaque réponse.
Nous avons maintenant établi la confiance au sein de notre zone, mais le DNS est un système hiérarchique et les zones fonctionnent rarement de manière indépendante. Pour compliquer encore les choses, la clé de signature de clé est signée par elle-même, ce qui n'apporte rien de plus à la confiance. Nous avons besoin d'un moyen de propager la confiance dans notre zone à sa zone parent.
Enregistrements signataires de délégation
DNSSEC introduit un enregistrement Delegation Signer (DS) pour permettre la propagation de la confiance dans une zone parent à une zone enfant. Un opérateur de zone hache l'enregistrement DNSKEY contenant la KSK publique et le donne à la zone parent pour qu'elle le publie en tant qu'enregistrement DS.
Chaque fois qu'un résolveur est dirigé vers une zone enfant, la zone parent fournit également un enregistrement DS. C'est grâce à cet enregistrement DS que les résolveurs savent que la zone enfant est compatible DNSSEC. Pour vérifier la validité de la KSK publique de la zone enfant, le résolveur la hache et la compare à l'enregistrement DS du parent. En cas de correspondance, le résolveur peut supposer que la KSK publique n'a pas été falsifiée ce qui signifie qu'il peut faire confiance à tous les enregistrements de la zone enfant. C'est ainsi qu'une chaîne de confiance est établie dans DNSSEC.
Notez que toute modification de la KSK nécessite de modifier l'enregistrement DS de la zone parent. La modification de l'enregistrement DS est un processus à plusieurs étapes qui peut finir par casser la zone si elle n'est pas effectuée correctement. Le parent doit commencer par ajouter le nouvel enregistrement DS, puis attendre que le TTL de l'enregistrement DS d'origine expire avant de le supprimer. C'est pourquoi il est beaucoup plus facile d'échanger des clés de signature de zone que des clés de signature de clé.
Déni d'existence explicite
Si vous demandez au DNS l'adresse IP d'un domaine qui n'existe pas, il renvoie une réponse vide : il n'existe aucun moyen de dire explicitement « Désolé, la zone que vous avez demandée n'existe pas ». Cette situation est problématique si vous voulez authentifier la réponse, puisqu'il n'y a pas de message à signer. DNSSEC résout ce problème en ajoutant les types d'enregistrements NSEC et NSEC3. Ils permettent tous deux un déni d'existence authentifié.
NSEC renvoie l'enregistrement « sécurisé suivant ». Prenons par exemple un serveur de noms qui définit des enregistrements AAAA pour api, blog, and www. Si vous demandez un enregistrement pour « store », il renvoie un enregistrement NSEC contenant www, ce qui signifie qu'il n'y a pas d'enregistrement AAAA entre « store » et www lorsque les enregistrements sont triés par ordre alphabétique. Vous savez ainsi que « store » n'existe pas. Et, puisque l'enregistrement NSEC est signé, vous pouvez valider son RRSIG correspondant comme n'importe quel RRset.
Malheureusement, cette solution permet à n'importe qui de traverser la zone et de rassembler tous les enregistrements sans savoir quels sont ceux qu'ils recherchent. Ce problème peut représenter une menace potentielle pour la sécurité si l'administrateur de la zone comptait sur la nature privée du contenu de la zone. Approfondissez ce problème en consultant l'article DNSSEC : Complexités et considérations, et lisez plus d'informations sur la solution unique de Cloudflare dans Application correcte de DNSSEC.
La chaîne de confiance
Très bien, nous avons donc un moyen d'établir la confiance au sein d'une zone et de la propager à sa zone parent, mais comment faisons nous confiance à l'enregistrement DS ? L'enregistrement DS est signé comme tout autre RRset, ce qui signifie qu'il a un RRSIG correspondant dans le parent. Tout le processus de validation se répète jusqu'à la KSK publique du parent. Pour procéder à la vérification, nous devons aller à l'enregistrement DS de ce parent, et remonter toute la chaîne de confiance.
Cependant, lorsque nous arrivons enfin à la zone DNS racine, un problème se pose : il n'existe aucun enregistrement DS parent pour le valider. C'est là que nous découvrons un aspect très humain de l'Internet mondial.
Lors de la Root Signing Ceremony, plusieurs personnes sélectionnées dans le monde entier se réunissent pour signer le RRset DNSKEY racine de manière très publique et hautement contrôlée. La cérémonie produit un enregistrement RRSIG qui peut être utilisé pour vérifier la KSK publique et la ZSK publique du serveur de nom racine. Au lieu de faire confiance à la KSK publique en raison de l'enregistrement DS du parent, nous supposons qu'il est valide parce que nous faisons confiance aux procédures de sécurité entourant l'accès à la KSK privée.
La capacité à établir la confiance entre les zones parent et enfant fait partie intégrante de DNSSEC. Si une partie de la chaîne est rompue, nous ne pouvons pas faire confiance aux enregistrements que nous demandons, car un homme du milieu pourrait modifier les enregistrements et nous diriger vers l'adresse IP de son choix.
Summary
Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.
Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.
We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.
Des millions de propriétés Internet nous font confiance
