Complexités et considérations relatives au DNSSEC

Le DNS est divisé en petits morceaux appelés zones. Une zone commence généralement par un nom de domaine et contient tous les enregistrements relatifs aux sous-domaines. Chaque zone est gérée par un seul gestionnaire. Par exemple, cloudflare.com est une zone contenant tous les enregistrements DNS pour cloudflare.com et ses sous-domaines (par ex. www.cloudflare.com, api.cloudflare.com).

Il n'existe pas de service d'annuaire pour les sous-domaines dans le DNS, par conséquent si vous voulez vérifier l'existence de api.cloudflare.com, vous devez interroger un serveur DNS qui à son tour interrogera cloudflare.com pour savoir si api.cloudflare.com existe. La procédure est différente avec DNSSEC. Dans certains cas, l'activation du DNSSEC peut exposer le contenu d'une zone autrement obscurcie. Pour certains la confidentialité des sous-domaines importe peu, et le contenu des zones peut déjà être facilement deviné car la plupart des sites ont un sous-domaine en « www ». Cependant, il arrive que les sous-domaines soient utilisés comme portails de connexion ou pour d'autres services que le propriétaire du site souhaite garder confidentiels. Un propriétaire de site peut ne pas vouloir révéler l'existence de « secretbackdoor.example.com » afin de protéger ce site des attaquants.

La raison pour laquelle DNSSEC peut exposer les sous-domaines est liée à la façon dont les zones sont signées. Traditionnellement, DNSSEC est utilisé pour signer les zones statiques. Une zone statique correspond à un ensemble complet d'enregistrements pour un domaine donné. Les enregistrements de signature DNSSEC sont créés à l'aide de la clé de signature de clé (KSK) et de la clé de signature de zone (ZSK) dans un emplacement central et envoyés au serveur de référence pour être publiés. Cet ensemble d'enregistrements permet à un serveur de référence de répondre à toutes les questions qui lui sont posées, y compris celles concernant des sous-domaines qui n'existent pas.

À la différence d'un DNS standard dans lequel le serveur renvoie une réponse NXDOMAIN (Non-Existent Domain) non signée lorsqu'un sous-domaine n'existe pas, le DNSSEC garantit une signature pour chaque réponse. Cela se fait au moyen d'un enregistrement spécial qui sert de preuve de non-existence, appelé enregistrement NextSECure (NSEC). Un enregistrement NSEC peut être utilisé pour indiquer : « Il n'y a pas de sous-domaines entre les sous-domaines X et le sous-domaine Y ». En remplissant l'espace entre chaque domaine de la zone, NSEC permet de répondre à toute requête avec un enregistrement statique. L'enregistrement NSEC précise également quels types d'enregistrements de ressources existent pour chaque nom.

Pour les zones à signature statique, il y a, par définition, un nombre fixe d'enregistrements. Chaque enregistrement NSEC renvoyant au suivant, il en résulte un « anneau » fini d'enregistrements NSEC couvrant tous les sous-domaines. N'importe qui peut « parcourir » une zone en suivant les enregistrements NSEC l'un après l'autre jusqu'à connaître tous les sous-domaines. Cette méthode peut être utilisée pour révéler tous les noms de cette zone, avec le risque d'exposer des informations internes.

Supposons qu'il existe une zone compatible DNSSEC appelée example.com, avec des sous-domaines public.example.com et secret.example.com. L'ajout d'enregistrements NSEC révélera l'existence de tous les sous-domaines.

Si vous demandez l'enregistrement NSEC de example.com, vous obtenez le résultat suivant :

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Si vous demandez l'enregistrement pour public.example.com vous obtenez :

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

Si vous interrogez pour secret.example.com vous obtenez l'enregistrement NSEC suivant :

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

Le premier correspond à la zone top/apex, et indique que le nom « example.com » existe et le nom suivant est « public.example.com ». L'enregistrement de public.example.com indique que le nom suivant est « secret.example.com » révélant l'existence d'un sous-domaine privé. L'enregistrement « secret.example.com » indique que l'enregistrement suivant est « example.com ». complétant la chaîne des sous-domaines. Par conséquent, avec quelques requêtes, n'importe qui peut connaître l'ensemble des enregistrements de la zone.

Techniquement, les enregistrements DNS ne sont pas censés être secrets, mais dans la pratique, ils sont parfois considérés comme tels. Les sous-domaines ont été utilisés pendant un certain temps pour préserver la confidentialité de certains éléments (comme la page de connexion d'une entreprise) et la révélation soudaine du contenu du fichier de zone peut être inattendue et mal perçue.

Avant le DNSSEC, la seule façon de découvrir le contenu des noms d'une zone était soit de les demander, soit de tenter d'effectuer un transfert de la zone à partir de l'un des serveurs de référence. Les transferts de zone (AXFR) sont fréquemment bloqués. La solution de remplacement au NSEC, NSEC3, a été introduite pour lutter contre les problèmes d'énumération des zones. Toutefois, même NSEC3 peut être utilisé pour révéler l'existence de sous-domaines.

La plupart des domaines sous .ch use NSEC3

L'enregistrement NSEC3 est semblable à un enregistrement NSEC à la différence près que plutôt que de donner un signer un espace vide pour les noms de domaines pour lesquels il n'y a pas de réponse à la question, NSEC3 signe un espace de hachages de noms de domaine. Le but était d'éviter l'énumération des zones. Ainsi, la chaîne NSEC3 pour une zone contenant « example.com ». et « www.example.com » pourrait se présenter ainsi (chaque enregistrement NSEC3 est sur 3 lignes pour plus de clarté) :

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Où

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

La première ligne de l'enregistrement NSEC3 contient le « nom » de la zone après hachage, le nombre de cycles de hachage et le sel utilisé pour le salage sont les deux derniers paramètres de la première ligne « 3 ABCDEF ». Le « 1 0 » représente l'algorithme de condensation (1 signifie SHA-1) et précise si la zone utilise Opt-out (0 signifie non). La deuxième ligne est le « nom haché suivant dans la zone », la troisième ligne énumère les types à ce nom. Vous pouvez voir que le « nom suivant » du premier enregistrement NSEC3 correspond au nom du deuxième enregistrement NSEC3 et que le « nom suivant » de ce dernier termine la chaîne.

Pour l'énumération NSEC, vous pouvez créer la liste complète des domaines en commençant par deviner les noms possibles dans le domaine. Si la zone comporte une centaine de noms de domaine, il faudra environ 100 requêtes pour énumérer la zone entière. Avec NSEC3, lorsque vous demandez un enregistrement qui n'existe pas, un enregistrement NSEC3 signé est renvoyé avec la zone présente suivante, classée par ordre alphabétique de hachage. En vérifiant si le nom candidat suivant peut s'inscrire dans l'un des espaces connus, il est possible de découvrir la chaîne complète en une centaine de requêtes. Il existe de nombreux outils qui peuvent effectuer ce calcul pour vous, notamment un module d'extension de nmap

Avec les hachages correspondant à tous les noms valides de la zone, une attaque par dictionnaire peut permettre de déterminer les noms réels. Les noms courts sont faciles à deviner et l'utilisation d'un dictionnaire permet de révéler l'existence de noms plus longs sans qu'il soit nécessaire de submerger les serveurs de noms de référence avec des suppositions. Des outils tels que HashCat facilitent cette tâche au niveau logiciel, et la popularité du bitcoin a fait baisser de façon spectaculaire le prix du matériel spécifique au hachage. Une véritable industrie en plein essor se consacre à l'élaboration de dispositifs conçus pour calculer des hachages cryptographiques. Le craqueur de mots de passe Tesla (ci-dessous) n'est qu'un exemple de ces dispositifs prêts à l'emploi.

Craqueur Teslsa

Le hachage n'étant pas de très bonne qualité, la confidentialité des zones n'est que légèrement améliorée lorsque l'on utilise NSEC3 tel qu'il est conçu ; le degré de protection d'un nom est proportionnel à la difficulté qu'on doit avoir à le deviner.

En résumé, NSEC équivaut à révéler des mots de passe en clair, et NSEC3 à révéler un fichier de mots de passe de type Unix. Aucune de ces deux techniques n'est très sûre. Avec NSEC3, un sous-domaine n'est privé que dans la mesure où il est difficile à deviner.

Cette vulnérabilité peut être atténuée par une technique présentée dans les RFC 4470 et 4471 (https://tools.ietf.org/html/rfc4470 et https://tools.ietf.org/html/rfc4471) appelée « DNSSEC white lies (les mensonges blancs) » ; elle a été mise en œuvre par Dan Kaminsky à des fins de démonstration. Lorsqu'une requête arrive pour un domaine qui n'est pas présent, au lieu d'un enregistrement NSEC3 du domaine réel suivant, c'est un enregistrement NSEC3 du hachage suivant dans l'ordre alphabétique qui est présenté. Cela ne remet pas en cause la garantie NSEC3 selon laquelle il n'existe aucun domaine dont le hachage s'inscrit lexicographiquement entre la réponse NSEC3 et la question.

Vous ne pouvez mettre en œuvre les « white lies » NSEC3 ou NSEC que si les signatures peuvent être calculées en temps réel en réponse à des questions. Traditionnellement, les enregistrements de zone statiques pour la résolution DNS sont créés hors ligne, et tous les enregistrements avec les signatures sont stockés dans un fichier de zone. Ce fichier est ensuite lu par un serveur DNS en direct, ce qui lui permet de répondre aux questions concernant la zone.

La mise en œuvre DNSSEC de Cloudflare s'appuie sur l'efficacité de la génération de signatures de l'algorithme ECDSA pour signer les enregistrements DNSSEC à la volée.

Le DNSSEC a été conçu pour fonctionner dans différents modes, chacun associé à des compromis différents en matière de sécurité, de performances et de commodité. La signature en direct résout le problème de l'exposition du contenu de la zone en contrepartie d'une gestion des clés moins sûre.

Le mode DNSSEC le plus courant est la signature hors ligne des zones statiques. Le système de signature est ainsi hautement protégé contre les menaces externes en conservant les clés privées sur une machine qui n'est pas connectée au réseau. Ce modèle de fonctionnement fonctionne bien lorsque les informations DNS ne changent pas souvent.

Un autre mode de fonctionnement est couramment appliqué, il s'agit de la signature centralisée en ligne. Si vous signez les données dans des systèmes de signature DNS dédiés à accès restreint, les données DNS peuvent être modifiées et publiées rapidement. Certains opérateurs exécutent la signature DNS sur leurs serveurs DNS principaux. À l'instar de la signature hors ligne des zones statiques, ce mode suit le modèle de signature centrale, c'est-à-dire qu'un signataire central unique (ou répliqué) procède à toutes les signatures et les données sont propagées depuis celui-ci vers les serveurs DNS de référence.

Un mode plus radical consiste à permettre aux serveurs DNS de référence de signer les données à la volée lorsque c'est nécessaire, ce qui permet le recours à un certain nombre de nouvelles fonctionnalités, notamment la signature, à l'endroit même où la réponse est générée, d'informations liées à des variables géographiques. Cette méthode comporte un inconvénient, à savoir que les données de clé se trouvent maintenant sur de nombreuses machines différentes qui ont un accès direct à l'internet. La signature en direct à la périphérie introduit de nouveaux problèmes tels que la répartition des clés et impose des exigences informatiques supplémentaires sur les nœuds.

Récemment, un bogue connu sous le nom de Heartbleed a été découvert et a ouvert une faille de sécurité majeure dans les applications de niveau serveur. Cela venait d'une erreur de codage dans OpenSSL qui créait une vulnérabilité de divulgation de mémoire à distance. Ce bogue permettait à des attaquants à distance d'extraire des clés cryptographiques de serveurs connectés à internet. Les bogues d'exposition de la mémoire distante ne sont qu'une des nombreuses menaces qui pèsent sur la sécurité des clés privées lorsque celles-ci sont utilisées dans un processus actif tel que la signature en direct de DNSSEC. Plus une machine est exposée à internet, plus les vecteurs d'attaque sont nombreux. Les machines de signature hors ligne sont beaucoup moins exposées à de telles menaces.

Il existe plusieurs façons de sécuriser les clés, l'une d'elle consiste à utiliser une solution matérielle telle qu'un module de sécurité matériel (HSM). Le principal inconvénient est le coût ; les HSM sont très chers (et lents). C'est l'un des points les plus délicats lorsqu'il s'agit d'exécuter des serveurs DNS vastement répartis géographiquement afin d'être au plus près de leurs clients. L'installation d'un HSM dans chaque emplacement de serveur peut non seulement être coûteuse, mais aussi s'avérer complexe d'un point de vue juridique.

Une autre solution pour protéger les clés contre la divulgation à distance consiste à transférer les opérations cryptographiques vers des composants de confiance du système. C'est là qu'il peut s'avérer utile de disposer d'un serveur DNS personnalisé vers lequel il est possible de se décharger de la cryptographie.

La gestion des clés pour les DNSSEC est similaire à la gestion des clés pour TLS et présente les mêmes difficultés. Au début de cette année, nous avons présenté la fonctionnalité SSL sans clé, l'objectif était d'améliorer la sécurité des clés pour TLS. Nous envisageons d'étendre le SSL sans clé pour mettre les avantages des serveurs de clés distants au service de la signature en direct des DNSSEC.

Les opérateurs qui gèrent un serveur DNS de référence sont souvent inquiets à l'idée que leur serveur soit utilisé comme un passage pour des attaques malveillantes par déni de service distribué (DDoS). Cela vient du fait que le DNS utilise UDP, un protocole sans état.

Dans le protocole TCP, chaque connexion commence par une négociation en trois temps. Cela permet de vérifier que l'adresse IP des deux parties est connue et correcte avant de lancer une connexion. Dans le protocole UDP, il n'y a pas de négociation :  les messages sont envoyés directement à une adresse IP sans que l'adresse IP d'origine ne soit vérifiée. Si un attaquant peut créer un paquet UDP disant « Bonjour, de l'IP X » à un serveur, le serveur répond généralement en envoyant un paquet UDP à X. Le fait d'indiquer l'adresse IP de la victime comme X au lieu de celle de l'expéditeur est appelé l'« usurpation » UDP. En usurpant l'identité d'une victime, un attaquant peut faire en sorte qu'un serveur, en répondant aux demandes UDP, inonde la victime de trafic « réfléchi ». Cela s'applique aussi bien aux serveurs de référence qu'aux résolveurs récursifs ouverts.

DNSSEC fonctionne également sur UDP, et les réponses aux requêtes DNS peuvent être très longues, contenant plusieurs enregistrements DNSKEY et RRSIG. Il s'agit d'une cible intéressante pour les attaquants, car elle leur permet d'« amplifier » leurs attaques par réflexion. Si un petit volume de requêtes DNSSEC UDP usurpées est envoyé aux serveurs de noms, la victime recevra un grand volume de trafic réfléchi. Cela suffit parfois à submerger le serveur de la victime et à provoquer un déni de service.

Demander un TLD qui n'existe pas à un serveur racine donne lieu à une réponse d'environ 100 octets, la réponse signée pour la même question est d'environ 650 octets, soit un facteur d'amplification de 6,5. La racine est signée à l'aide d'une clé RSA de 1 024 bits et utilise NSEC pour les réponses négatives. En domandant un domaine qui n'existe pas dans un TLD en utilisant NSEC3 signé avec une clé de 1 024 bits vous obtiendrez un facteur d'amplification d'environ 10. Il existe d'autres requêtes qui peuvent donner lieu à des facteurs d'amplification encore plus élevés, la plus efficace étant la requête « ANY ».

À l'instar de nombreux services, le DNS peut également fonctionner sur TCP. Il existe un indicateur « troncature » qui peut être renvoyé à un résolveur pour indiquer que le protocole TCP est nécessaire. Cela permettrait de résoudre le problème de la réflexion DNS au prix d'un ralentissement des requêtes DNS. Cette solution n'est pas commode pour le moment puisque 16 % des résolveurs ne respectent pas l'indicateur de troncature TCP, et 4 % n'essaient pas de deuxième serveur.

Une autre option pour réduire la taille des réponses consiste à utiliser des clés Elliptic Curve Digital Signature Algorithm (ECDSA) au lieu des clés RSA traditionnelles. Les clés ECDSA sont beaucoup plus petites que les clés RSA de force équivalente, et elles produisent des signatures plus petites, ce qui rend les réponses DNSSEC beaucoup plus petites et réduit le facteur d'amplification. Google Public DNS a ajouté la prise en charge de l'algorithme ECDSA fin 2014, et plusieurs autres ont suivi depuis.

La prise en charge de TCP et ECDSA reste à la traîne par rapport à la prise en charge générale de DNSSEC, les méthodes traditionnelles de lutte contre les abus peuvent donc être utilisées à la place. Cela comprend la limitation du débit de réponse et d'autres méthodes heuristiques.

Pour garantir la protection contre les attaques par réflexion, Cloudflare travaille à l'élaboration d'une stratégie pluridimensionnelle. Premièrement, en utilisant les heuristiques d'identification des attaques et les techniques anti-abus que nous utilisons actuellement dans notre serveur DNS, et deuxièmement en réduisant le facteur d'amplification des réponses DNSSEC. Les moyens de réduire le facteur d'amplification maximal consistent à ne répondre qu'aux requêtes « ANY » sur TCP, à utiliser des clés ECDSA plus petites lorsque cela est possible et à réduire la fréquence des renouvellements de clés.

Cloudflare est conscient de la complexité introduite par le protocole DNSSEC en matière de confidentialité de la zone, de gestion des clés et de risque de réflexion/amplification. Il est possible d'écarter les risques liés à DNSSEC avec des décisions techniques judicieuses, et la mise en place de contrôles opérationnels.