DNS sur HTTPS Oblivieux (ODoH) : une tentative d'améliorer la confidentialité DNS

Le système de noms de domaine ou DNS est un système de nommage décentralisé pour tous les différents sites web qui existent sur Internet. C’est l’un des éléments essentiels de l’Internet et il existe depuis plus de trois décennies. Au cours de cette période, le système a été soumis à des critiques, avec des arguments valables, concernant sa mise en œuvre et les préoccupations en matière de confidentialité qu’il entraîne. En conséquence, il y a eu quelques tentatives pour répondre à ces préoccupations.

Une telle tentative — et une très récente — est l’introduction du protocole DNS sur HTTPS (DoH), qui promet de sécuriser la communication DNS en la transmettant de manière cryptée. Bien que le DoH semble prometteur en théorie et parvienne à résoudre l’un des problèmes du DNS, il met involontairement en lumière une autre préoccupation. Pour y remédier, nous avons maintenant un autre nouveau protocole, appelé DNS sur HTTPS Oblivieux (ODoH), qui a été co-développé par Cloudflare, Apple et Fastly. Le DoH Oblivieux est essentiellement une extension du protocole DoH qui découple les requêtes DNS des adresses IP (de l’utilisateur) pour empêcher le résolveur DNS de connaître les sites que visite un utilisateur — un peu [plus à ce sujet plus tard].

“Ce que l’ODoH est censé faire, c’est séparer les informations sur qui fait la requête et ce qu’est la requête“, a déclaré Nick Sullivan, responsable de la recherche chez Cloudflare, dans un blog.

DNS sur HTTPS Oblivieux (ou ODoH)

Avant de plonger directement dans ce qu’est l’ODoH, comprenons d’abord ce qu’est le DNS, et par la suite, le DNS sur HTTPS, ainsi que les limitations que les deux présentent.

DNS (Système de Noms de Domaine)

Le système de noms de domaine ou DNS est un système décentralisé de conservation des enregistrements de tous les sites web sur Internet. Vous pouvez le considérer comme un dépôt (ou annuaire téléphonique) pour les numéros de téléphone qui contient une liste d’abonnés téléphoniques et leurs numéros de téléphone correspondants.

En termes d’Internet, le DNS est un acteur critique dans l’établissement d’un système qui vous permet d’accéder à un site web simplement en entrant son nom de domaine, sans avoir besoin de mémoriser son adresse IP (Internet Protocol) associée. Grâce à cela, vous pouvez entrer techpp.com dans le champ d’adresse pour voir ce site sans avoir à vous souvenir de son adresse IP, qui pourrait ressembler à quelque chose comme 103.24.1.167 [pas notre IP]. Vous voyez, c’est l’adresse IP qui est nécessaire pour établir une connexion entre votre appareil et le site web que vous essayez d’accéder. Mais comme une adresse IP n’est pas aussi facile à mémoriser qu’un nom de domaine, il est nécessaire d’avoir un résolveur DNS pour résoudre les noms de domaine en leurs adresses IP associées et renvoyer la page web demandée.

Problème avec le DNS

Bien que le DNS simplifie l’accès à Internet, il présente quelques lacunes — la plus importante étant le manque de confidentialité (et de sécurité), ce qui pose un risque pour les données des utilisateurs et les expose à être vues par le FAI ou à être écoutées par un mauvais acteur sur Internet. La raison pour laquelle cela est possible est due au fait que la communication DNS (requête/ réponse DNS) est non cryptée, ce qui signifie qu’elle se fait en texte clair, et peut donc être interceptée par quiconque se trouve entre l’utilisateur et le FAI.

DoH (DNS sur HTTPS)

Comme mentionné au départ, le protocole DNS sur HTTPS (DoH) a été introduit pour répondre à cette préoccupation (de sécurité) DNS. Essentiellement, ce que fait le protocole, c’est qu’au lieu de laisser la communication DNS — entre le client DoH et le résolveur basé sur DoH — se faire en texte clair, il utilise le cryptage pour sécuriser la communication. Ce faisant, il parvient à sécuriser l’accès des utilisateurs à Internet et à réduire les risques d’attaques de type homme du milieu — dans une certaine mesure.

Problème avec le DoH

Bien que le DoH aborde le problème de la communication non cryptée sur le DNS, il soulève une préoccupation en matière de confidentialité — concernant le fait de mettre le fournisseur de services DNS en plein contrôle de vos données réseau. En effet, puisque le fournisseur DNS agit comme un intermédiaire entre vous et le site web que vous accédez, il détient un enregistrement de votre adresse IP et des messages DNS. D’une certaine manière, cela soulève deux préoccupations. Premièrement, cela laisse une seule entité avec accès à vos données réseau — permettant au résolveur de lier toutes vos requêtes à votre adresse IP, et deuxièmement, à cause de la première préoccupation, cela rend la communication vulnérable à un point de défaillance unique (attaque).

Protocole ODoH et son fonctionnement

Le dernier protocole, ODoH, co-développé par Cloudflare, Apple et Fastly, vise à résoudre le problème de centralisation du protocole DoH. Pour cela, Cloudflare suggère que le nouveau système sépare les adresses IP des requêtes DNS afin qu’aucune entité unique, sauf l’utilisateur, ne puisse voir les deux morceaux d’information en même temps.

L’ODoH s’attaque à ce problème en mettant en œuvre deux changements. Il ajoute une couche de cryptage à clé publique et un proxy réseau entre le client (utilisateur) et le serveur DoH. Ce faisant, il prétend garantir que seul l’utilisateur a accès à la fois aux messages DNS et aux adresses IP à un moment donné.

En résumé, l’ODoH agit comme une extension du protocole DoH qui vise à atteindre les objectifs suivants :

i. empêcher le résolveur DoH de savoir quel client a demandé quels noms de domaine en canalisant les requêtes via un proxy pour supprimer les adresses des clients,

ii. empêcher le proxy de connaître le contenu des requêtes et des réponses, et empêcher le résolveur de connaître les adresses des clients en cryptant la connexion en couches.

Flux de messages avec ODoH

Pour comprendre le flux de messages avec ODoH, considérez la figure ci-dessus, où un serveur proxy se trouve entre le client et la cible. Comme vous pouvez le voir, lorsque le client demande une requête (disons example.com), celle-ci est envoyée au serveur proxy, qui la transmet ensuite à la cible. La cible reçoit cette requête, la déchiffre et génère une réponse en envoyant la demande au résolveur (récursif). Sur le chemin du retour, la cible crypte la réponse et la transmet au serveur proxy, qui la renvoie ensuite au client. Enfin, le client déchiffre la réponse et obtient une réponse à sa requête demandée.

Dans ce cadre, la communication — entre le client et le proxy et entre le proxy et la cible — se fait via HTTPS, ce qui ajoute à la sécurité de la communication. Non seulement cela, mais l’ensemble de la communication DNS se déroulant sur les deux connexions HTTPS — client-proxy et proxy-cible — est crypté de bout en bout afin que le proxy n’ait pas accès au contenu du message. Cela dit, bien que la confidentialité et la sécurité des utilisateurs soient prises en compte dans cette approche, la garantie que tout fonctionne comme suggéré repose sur une condition ultime — le proxy et le serveur cible ne doivent pas conspirer. Par conséquent, la société suggère que “tant qu’il n’y a pas de collusion, un attaquant ne réussit que si le proxy et la cible sont compromis.”

Selon un blog de Cloudflare, voici ce que garantissent le cryptage et le proxy :

i. La cible ne voit que la requête et l’adresse IP du proxy.

ii. Le proxy n’a aucune visibilité sur les messages DNS, sans possibilité d’identifier, de lire ou de modifier soit la requête envoyée par le client, soit la réponse renvoyée par la cible.

iii. Seule la cible prévue peut lire le contenu de la requête et produire une réponse.

Disponibilité de l’ODoH

Le DNS sur HTTPS Oblivieux (ODoH) est juste un protocole proposé pour l’instant et doit être approuvé par l’IETF (Internet Engineering Task Force) avant d’être adopté sur le web. Même si Cloudflare suggère qu’à ce jour, il a des entreprises comme PCCW, SURF et Equinix comme partenaires proxy pour aider au lancement du protocole et qu’il a ajouté la capacité de prendre des requêtes ODoH sur son service DNS 1.1.1.1, la vérité est que, à moins que les navigateurs web n’ajoutent nativement le support du protocole, vous ne pouvez pas l’utiliser. En effet, le protocole est encore en phase de développement et est testé pour la performance à travers différents proxies, niveaux de latence et cibles. Pour cette raison, il peut ne pas être judicieux de décider du sort de l’ODoH immédiatement.

D’après les informations et les données disponibles, le protocole semble prometteur pour l’avenir du DNS — à condition qu’il parvienne à atteindre le type de confidentialité qu’il promet sans compromettre la performance. Il est désormais très évident que le DNS, qui joue un rôle critique dans le fonctionnement de l’Internet, souffre encore de problèmes de confidentialité et de sécurité. Et malgré l’ajout récent du protocole DoH qui promet d’ajouter à l’aspect sécurité du DNS, l’adoption semble encore lointaine en raison des préoccupations en matière de confidentialité qu’il soulève.

Mais, si l’ODoH parvient à tenir ses promesses en matière de confidentialité et de performance, sa combinaison avec le DoH, tout en travaillant en tandem, peut répondre à la fois aux préoccupations de confidentialité et de sécurité du DNS. Et à son tour, rendre le DNS beaucoup plus privé et sécurisé qu’il ne l’est aujourd’hui.