Sécurité DNS – DoH : Qu’est-ce le DNS over HTTPS ?

I. Présentation

Le DNS over HTTPS (DoH) est une norme qui a pour objectif de chiffrer les requêtes DNS entre votre machine et votre serveur DNS. Comment fonctionne-t-il ? Est-il fiable ? Est-ce que ce protocole permet de protéger ma vie privée ? Différentes questions se posent et dans ce premier article sur le sujet, je vais vous en parler.

🎥 Vidéo complète sur le sujet : de la théorie à la pratique avec la configuration des navigateurs et une démo sous Windows 10 avec une rapide analyse de trames.

Le DNS est l'un des protocoles les plus anciens et surtout, c'est un protocole indispensable que l'on utilise tous au quotidien. Pour rappel, il sert à traduire les noms de domaine en adresse IP, alors d'un point de vue des utilisateurs il facilite grandement l'utilisation d'Internet au quotidien. On retient le nom de domaine d'un site, et non son adresse IP sinon cela pourrait être compliqué.

Néanmoins, le protocole DNS a beau être précieux, il a une faiblesse majeure : il n'a pas été pensé pour être sécurisé (comme les autres protocoles de sa génération, en fait). Forcément cela pose des problèmes, d'autant plus que ces dernières années le respect de la vie privée est devenu un enjeu majeur, tout comme la sécurité des données au sens large.

Aujourd'hui, le protocole HTTP non sécurisé dispose d'une version sécurisée avec le HTTPS, les protocoles de messagerie disposent aussi de versions sécurisées, etc... Quid du protocole DNS ?

Psst... Si vous ne maîtrisez pas la notion de DNS, je vous propose de découvrir ma vidéo "Le DNS pour les débutants" :

II. La notion de résolveur DNS

Le résolveur DNS correspond au serveur DNS sollicité lorsque votre machine a besoin de traduire un nom de domaine en adresse IP. Une étape indispensable pour contacter le bon serveur et accéder à votre site préféré.

Concrètement, lorsque vous contactez un site Internet en saisissant son nom de domaine directement dans la barre d'adresse, votre machine va envoyer une requête DNS au résolveur DNS pour lui poser une question simple : "Peux-tu m'indiquer l'adresse IP correspondante au site it-connect.fr ?". Si la réponse est connue, le serveur va répondre : "L'adresse IP du site it-connect.fr est 1.2.3.4", et votre machine va se connecter sur ce serveur.

Pour obtenir cette réponse, le résolveur va regarder dans son cache s'il a déjà l'information et si elle est toujours valide. Dans le cas où il n'a pas l'information, il va contacter le serveur DNS faisant autorité pour la zone de notre domaine afin de l'obtenir.

Sur Windows, on peut obtenir facilement l'adresse IP correspondante à un nom de domaine grâce à l'outil natif "nslookup". Il existe aussi sous Linux, mais il y a d'autres alternatives. L'utilisation basique de cet outil consiste à préciser le nom de domaine à résoudre : le résolveur DNS configuré sur votre machine (votre carte réseau) sera sollicité.

nslookup www.france.fr

A. L'échange entre la machine et le résolveur DNS est-il sécurisé ?

Cet échange entre votre machine et le résolveur DNS s'effectue en clair sur le réseau.

Lorsqu'un échange s'effectue en clair sur le réseau, cela signifie que le contenu de la requête, c'est-à-dire le contenu du message, est lisible. Autrement dit, il n'est pas protégé par du chiffrement.

Si un attaquant intercepte cette requête, il pourrait la consulter, la modifier et vous retourner une réponse falsifiée dont l'objectif serait de vous orienter vers un site Internet malveillant. Ce site malveillant pourrait être une copie du site sur lequel vous souhaitez accéder dans le but de récupérer vos identifiants de connexion, par exemple. Dans ce cas, nous parlerons d'une attaque de l'homme du milieu (man in the middle) où "l'homme du milieu" est représenté par l'attaquant puisqu'il se situe entre vous et le résolveur DNS.

Par défaut, le protocole DNS n'a pas de mécanisme pour s'assurer de l'authenticité de la réponse : qu'est-ce qui me garantit que je vais bien consulter le bon site Internet ? Autrement dit, le serveur DNS peut renvoyer n'importe quelle adresse IP, le client DNS lui fera confiance.

Cet exemple (il y en a d'autres) met en évidence ce besoin de sécuriser les échanges entre votre machine et le résolveur DNS.

B. Quel résolveur DNS doit-on utiliser ?

Au-delà de la problématique autour de la sécurité des échanges, il y a une autre question que l'on peut se poser : quel résolveur DNS doit-on utiliser ? Est-ce qu'il y a des résolveurs DNS plus fiables que d'autres ?

Prenons un exemple. Lorsque vous êtes chez vous et que vous utilisez la configuration par défaut de votre Box, vous utilisez les serveurs DNS de votre fournisseur d'accès à Internet (FAI). À première vue, ces résolveurs DNS sont fiables et, éventuellement, on peut dire qu'ils sont neutres. Mais ce n'est pas le cas.

Dans le cas où une décision de justice ordonne le blocage d'un site spécifique (ce qui est déjà arrivé pour des dizaines de sites de streaming tels que Allostream et Time2watch), les serveurs DNS des FAI ne répondront plus aux requêtes lorsqu'un client DNS demande l'adresse IP correspondante à un domaine bloqué. Pourtant le site existe et il est en ligne. On parle alors de résolveurs DNS menteurs.

En alternative, nous avons bien sûr les DNS de Google notamment le fameux "8.8.8.8" que certains connaissent surement. Disons que Google n'est pas réputé pour respecter la vie privée des utilisateurs donc si on peut en trouver un autre, ce n'est pas plus mal. Utiliser le DNS de Google, cela veut dire que l'on autorise Google à garder l'historique de nos requêtes DNS et potentiellement, à l'exploiter. Mais alors, quel résolveur DNS choisir ?

En parlant du DNS de Google, il y a d'ailleurs une histoire assez incroyable à ce sujet. En 2014, la Turquie avait décidé de bloquer Twitter et YouTube. Pour contourner cette censure, les internautes turcs utilisaient les DNS de Google. Pour faire passer le message, il y avait même des inscriptions sur les bâtiments pour diffuser l'adresse du DNS de Google. Le gouvernement a contre-attaqué en demandant aux FAI que les DNS de Google soient bloqués en redirigeant les requêtes vers des sites mis en place par les FAI.

Comme alternative à Google, il y a depuis 2018, le résolveur DNS du géant Cloudflare que vous pouvez utiliser en utilisant l'adresse IP "1.1.1.1". Il se veut rapide et respectueux de la vie privée, je pense que c'est un bon choix, mais il reste américain. Dans le doute, vous pouvez vous tourner vers le résolveur DNS Quad9, exploité par la Fondation Quad9 basée en Suisse et accessible à l'adresse IP 9.9.9.9 (d'où le nom Quad9). Je reviendrai plus en détail sur le choix du résolveur DNS au moment d'en choisir un à utiliser avec le protocole DNS over HTTPS : tous les résolveurs ne sont pas compatibles.

En fait, ce qu'il faut retenir c'est que le résolveur DNS n'est pas là pour sécuriser le protocole DNS, mais il a un rôle à jouer dans le respect de la vie privée : en quelque sorte, vous devez avoir confiance en votre résolveur DNS.

Pour vous convaincre que le résolveur DNS a un rôle à jouer dans le respect de la vie privée, lisez ce qui suit... Si vous utilisez toujours le même résolveur et que celui-ci garde un historique de vos requêtes DNS, ce dernier pour facilement retracer l'ensemble des sites sur lesquels vous vous rendez. Votre adresse IP publique (qui est un peu comme votre adresse postale sur Internet) sera liée à un ensemble de noms de domaine, ce qui permettra de dresser un profil type. Par exemple si l'adresse IP 3.4.5.6 demande l'adresse IP correspondant au site it-connect.fr, puis openclassrooms.com, puis pole-emploi.fr. On peut deviner que vous recherchez un emploi dans l'informatique et que vous êtes sans emploi, étudiant ou en reconversion professionnelle (simple exemple).

III. Quelles solutions pour sécuriser les échanges DNS ?

Pour répondre à la question "comment sécuriser les échanges DNS ?", il y a plusieurs pistes à explorer. Plusieurs termes reviennent souvent : DNSSEC, DNS over TLS, DNS over HTTPS, voire même DNSCrypt. Dans le cadre de la présentation de DNS over HTTPS, je vais m'intéresser aux trois premiers cités.

A. DNSSEC

Le DNSSEC (Domain Name System Security Extensions) est un protocole de communication qui a pour objectif d'apporter une couche de sécurité au protocole DNS. Les ingénieurs de l'IETF l'ont créé dans les années 1990.

Par l'intermédiaire de signatures numériques, le propriétaire d'une zone DNS va pouvoir signer les données des enregistrements DNS. C'est bien le contenu de la zone qui est signé et sécurisé, non pas les requêtes DNS. L'objectif étant d'authentifier le serveur qui répond à la requête DNS, mais aussi de s'assurer de l'intégrité de la réponse (pour être sûr qu'elle n'a pas été modifiée).

Cette méthode s'appuie sur de la cryptographie à clé publique où chaque zone dispose d'une paire de clés publique-privée. La clé privée reste secrète tandis que la clé publique sera publiée dans la zone directement. C'est intéressant, car cela va permettre à un résolveur DNS de vérifier l'authenticité des données de la zone DNS grâce à la clé publique et à la vérification des signatures. Dans le cas où l'authentification des données est réussie, le résolveur DNS retourne la réponse au client DNS, alors que si la signature est incorrecte, une erreur est renvoyée au client DNS. Cela peut signifier qu'il s'agit d'une attaque.

Concrètement, DNSSEC va permettre de lutter contre différentes attaques, et particulièrement l'empoisonnement du cache DNS, qui consiste à envoyer de fausses informations à un résolveur DNS qui cherche à résoudre un nom. Cette fausse information sera ensuite envoyée aux clients DNS. On dit que le cache est empoisonné, car il contient de fausses informations.

Pour que le mécanisme de protection de DNSSEC soit pleinement efficace, il faut que l'ensemble de la chaîne soit signée pour créer une chaîne de confiance. En fait, si l'on prend l'exemple du domaine "it-connect.fr", il faut appliquer DNSSEC sur la zone "it-connect.fr", mais également sur la zone ".fr" qui correspond à son domaine de premier niveau (ccTLD, gTLD, etc.). Rassurez-vous, c'est le cas pour toutes ces zones de premiers niveaux.

Pour activer le DNSSEC sur un domaine, au niveau de votre hébergeur ce n'est pas plus compliqué que de cocher une case dans les options de votre domaine. Par exemple chez OVH, il y a une option nommée "Délégation sécurisée - DNSSEC". Sachez également que DNSSEC peut être activé pour sécuriser la zone DNS d'un annuaire Active Directory.

Le DNSSEC est un premier pas en avant puisqu'il permet de s'assurer que le contenu de la réponse que l'on reçoit est authentique, qu’elle est saine et qu'elle correspond bien à notre requête. Néanmoins, il n'apporte pas de réponse à la problématique suivante : comment chiffrer les échanges DNS entre la machine et le résolveur DNS ?

B. DNS over TLS

Le DNS over TLS (DoT) est une norme qui a pour objectif de chiffrer le trafic DNS et permettre de sécuriser les échanges entre une machine et un résolveur DNS. Grâce à ce chiffrement, les attaquants (ainsi que les FAI) ne peuvent pas lire les données du trafic DNS, ni le modifier : une excellente protection contre les attaques de type "homme du milieu".

Le protocole TCP est utilisé pour établir la connexion par l'intermédiaire du port 853. Il s'agit d'un port dédié et cela peut s'avérer contraignant si le port est bloqué par le pare-feu qui se situe en sortie de votre réseau. Les paquets DNS sont chiffrés avec le protocole TLS pour sécuriser leur transmission.

C. DNS over HTTPS

Le DNS over HTTPS (DoH) est également une norme et elle est similaire au DNS over TLS. Clairement, son objectif est de chiffrer les échanges entre la machine qui effectue la requête DNS et le résolveur DNS en lui-même.

Là où il est différent, c'est dans son fonctionnement. Le protocole HTTPS est utilisé pour établir la connexion, ce qui implique que l'on utilise un port standard et qui sera celui du HTTPS : le port 443. Le trafic DNS quant à lui sera encapsulé au sein de la connexion HTTPS, tout en sachant que cette connexion bénéficie du chiffrement via TLS.

L'intérêt du DNS over HTTPS en comparaison du DNS over TLS, c'est qu'il utilise un protocole et un port standard : le HTTPS/443. Ce qui va lui permettre de passer plus facilement au travers des pare-feux, mais aussi de noyer les requêtes DNS dans la masse de trafic HTTPS.

Note : Le DNS over HTTPS correspond à la RFC 8484

Le DoH est probablement plus intéressant pour améliorer le respect de la vie privée des utilisateurs. Par contre, le trafic est difficilement identifiable, ce qui complique la tâche des administrateurs.

IV. DNS over HTTPS : quel résolveur choisir ?

Comme nous venons de le voir, le DoH permet de chiffrer les échanges DNS. Par contre, le résolveur DNS que l'on utilise sera toujours en mesure de savoir ce qu'on lui a demandé comme requête DNS : la requête n'est pas anonyme, elle est envoyée depuis notre machine.

Si l'on veut vraiment aller jusqu'au bout des choses, non seulement il faut utiliser le DNS over HTTPS pour sécuriser les échanges DNS, mais il faut aussi choisir un résolveur DNS dans lequel nous avons confiance. Un résolveur DNS respectueux de la vie privée, en fait. Le DoH n'empêchera pas le serveur DNS de mentir comme c'est le cas lorsqu'un FAI bloque un site suite à une décision de justice, et il n'empêchera pas non plus le résolveur DNS de collecter les données sur les requêtes DNS émises par les clients DNS.

Un bon résolveur DNS est un résolveur DNS qui n'applique pas de censure (à part éventuellement contre les sites malveillants) et qui ne collecte pas de données liées à l'utilisation. S'il est massivement utilisé c'est encore mieux, comme ça votre trafic sera noyé dans la masse. Les résolveurs DNS de Cloudflare et Quad9 sont compatibles DoH et ils me semblent pertinents, avec une petite préférence pour le second qui est basé en Europe (Suisse). Si vous en connaissez un, n'hésitez pas à partager l'information.

La théorie est posée, maintenant il reste à voir comment utiliser DoH sur son ordinateur, sa tablette ou son smartphone.

La bonne nouvelle, c'est que dans les prochains articles, nous verrons comment utiliser le DNS over HTTPS avec différents navigateurs (Firefox, Chrome, Edge ou encore Brave), mais aussi sur Windows 10.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio