DNS over HTTPS est un protocole permettant de chiffrer les requêtes DNS et protéger leur intégrité. En théorie, il devient impossible de suivre ce qui a été consulté ou de dévier le trafic. Une solution intéressante sur le papier, mais qui pose question dans ses premières implémentations. On vous explique pourquoi.
Ces dernières années, le respect de la vie privée et la sécurité des données sont devenus des enjeux majeurs. Ce, tant pour résister à des attaques de pirates que pour contrer un espionnage dont les États ne se cachent pas.
Si l'on pense souvent au chiffrement des fichiers, des emails, des flux de communication via les accès sécurisés (HTTPS) et des protocoles comme TLS, on en oublie parfois des briques moins visibles, mais tout aussi essentielles. C'est le cas du DNS (Domain Name System), autre grand maillon de la chaîne permettant de convertir des noms de domaine facile à retenir en adresses IP permettant aux équipements réseau de communiquer entre eux.
Créé il y a près de 40 ans, utilisé au quotidien par des milliards d'internautes, son fonctionnement fait débat. Car même si vous naviguez sur des sites de manière sécurisée (HTTPS), rien n'empêche la structure hébergeant les serveurs DNS que vous utilisez de savoir précisément les sites que vous avez consultés.
Le DNS : un élément simple au centre de nombreux enjeux
Dans la pratique, qu'est-ce qu'un résolveur DNS ? Lorsque vous voulez accéder à un site web, vous tapez son adresse (URL) dans la barre principale de votre navigateur. Pour ce faire, votre machine doit savoir à quel serveur s'adresser. Pour cela, elle doit connaître son adresse IP. Fournir cette réponse, c'est le rôle de l'application que l'on appelle résolveur DNS.
Elle a été pensée pour être simple et peu gourmande en ressource. Il suffit ainsi de lui envoyer une requête (passant par le port 53) pour avoir une réponse. Des outils permettent de le faire simplement avec un résultat plus ou moins détaillé. Par exemple nslookup sous Windows ou host sous Linux (vous pouvez également utiliser ceux de dnsutils) :
La réponse du résolveur DNS d'une Livebox pour le site du gouvernement, avec le détail de ses alias
Dans la pratique, lorsqu'une requête est effectuée, le résolveur regarde dans son cache, s'il connaît déjà la réponse. Si ce n'est pas le cas, il remonte la chaîne du nom de domaine, s'adressant d'abord aux serveurs racines (.), qui le renverront ensuite vers celui du domaine de premier niveau (TLD, « fr » et donc l'AFNIC dans notre exemple), puis de second niveau (SLD, « gouvernement » ), le sous-domaine (« www »), etc. En bout de chaîne, c'est en général l'hébergeur qui répond.
Notez que cela ne concerne pas que les sites que vous visitez, mais également pour toutes les requêtes des éléments qu'ils intègrent au sein de leurs pages : images, scripts, publicités, etc.
Pour l'internaute, cette brique logicielle est le plus souvent invisible puisqu'elle est fournie par la box de son opérateur. Lorsque vous vous y connectez pour accéder à internet elle attribue automatiquement une adresse IP à votre machine via le protocole DHCP, puis se déclare comme passerelle et serveur DNS de référence.
L'intérêt pour l'utilisateur, c'est qu'il n'a rien à faire. Le problème, c'est que ces DNS peuvent être « menteurs ». C'est à dire renvoyer une réponse fausse. C'est notamment le cas lorsque la justice demande le blocage d'un site par les fournisseurs d'accès : pour une liste de noms de domaines, ils ne renvoient pas l'adresse IP correspondante.
Une procédure récemment mise en application pour des sites de streaming par exemple. Mais parfois, il y a des ratés. Comme lorsqu'Orange avait bloqué par erreur de très nombreux sites en 2016, redirigeant ses clients vers la fameuse page à la « main rouge » devant s'afficher à la place de sites à caractère terroriste.
Dès lors, on conseille le plus souvent d'utiliser d'autres résolveurs DNS que ceux des FAI, non menteurs. Il y a bien ceux de Google, mais cela revient à faire connaître toute votre navigation au géant américain. Même s'il affirme ne pas exploiter ces données, certains sont méfiants et se tournent vers French Data Network (FDN), 1.1.1.1 (Cloudflare) ou Quad9.
Vous pouvez également installer simplement votre propre résolveur DNS, sur votre machine, un serveur ou un NAS, etc. Mais d'une certaine manière, cela ne fait que déplacer le problème, des requêtes étant tout de même effectuées vers des serveurs tiers (racine, premier et second niveau, etc.) lorsque le cache local n'est pas utilisé.
Le besoin de chiffrement du DNS
Mais dans tous les cas, le DNS fait face à un problème qui tient à sa conception : les requêtes ne sont pas chiffrées et circulent donc en clair sur l'ensemble de la chaîne. On peut certes minimiser les échanges, mais cela reste un problème.
Car elles peuvent être interceptées (notamment sur un réseau Wi-Fi ouvert par exemple), modifiées, et sont connues par les serveurs qui auront à vous répondre. À ce titre, la position des fournisseurs d’accès vers qui la police peut se tourner en cas d’enquête pour fournir ces informations diffusées en clair, pose particulièrement question.
Ces dernières années, de multiples initiatives ont été lancées pour renforcer la sécurité de cette brique essentielle. Il y a bien entendu DNSSEC, qui permet d'ajouter une signature cryptographique aux enregistrements DNS, permettant d'en vérifier la validité. Mais même après quelques années, sa mise en place reste minoritaire.
La conférence DNS et vie privée de Shaft
Depuis, d'autres initiatives ont vu le jour, comme DNSCrypt, GNUnet, DNS over TLS (DoT), etc. Mais aucune n'a été largement implémentée. C'est là qu'intervient DNS over HTTPS (DoH), qui semble désormais faire consensus. Proposant d'encapsuler les requêtes DNS dans une requête HTTPS, qui est donc chiffrée, il a de nombreux avantages.
Mais bien qu’elle soit en théorie un apport majeur à la vie privée, ce n’est pas une panacée.
DoH, comment ça marche ?
Cette solution est récente, ayant fait l’objet d’une standardisation par l’IETF (Internet Engineering Task Force) en octobre 2018 (RFC 8484). Le mécanisme décrit comment les requêtes et réponses sont chiffrées, encapsulées dans un flux HTTPS.
Une solution intéressante puisqu'elle exploite des technologies assez basiques et maitrisées. Surtout, DoH se repose sur le port 443 utilisé pour les connexions sécurisées, très rarement bloqué. Là où DoT nécessite l'accès au port 853. Elle profite également d'autres avantages comme l'assurance de l'origine de la réponse et de sa non-altération. DoH permet ainsi de se prémunir de toute attaque impliquant un tiers, de l’homme du milieu aux middleboxes.
Là aussi, on peut en vérifier le fonctionnement via des outils simples, comme les versions récentes de curl :
curl -v --doh-url https://dns.quad9.net/dns-query www.gouvernement.fr
Dans cet exemple, on demande au serveur DoH de Quad9 de nous donner le résultat pour le site du gouvernement. D'autres résolveurs peuvent être utilisés, une liste est proposée par ici ou par là. La requête est envoyée, via HTTP/2 (obligatoire pour DoH) avec TLS 1.3. On reçoit ensuite une longue réponse, dont les éléments suivants :
* DOH Host name: www.gouvernement.fr
* TTL: 175 seconds
* DOH A: 8.249.51.252
* DOH A: 8.252.38.252
* DOH A: 67.26.251.252
* CNAME: www.premier-ministre.gouv.fr
* CNAME: sni.www.gouvernement.fr.c.footprint.net
* CNAME: www.premier-ministre.gouv.fr
* CNAME: sni.www.gouvernement.fr.c.footprint.net
Quad9 permet aussi d'effectuer la requête dans un simple navigateur, avec un résultat au format JSON :
https://dns.quad9.net:5053/dns-query?name=www.gouvernement.fr
Dans ces deux cas on retrouve le résultat obtenu via la méthode classique, avec une différence de taille : notre FAI ne voit ici passer qu'un échange chiffré, sans savoir pour quel site une requête DNS est effectuée.
Reste tout de même un problème dans cette façon de faire : dans le cas ci-dessus, Quad9 sait ce qui lui a été demandé, par quelle machine. De plus, utiliser un DNS over HTTPS n'assure que du chiffrement et de l'intégrité, pas du comportement et de l'éthique du résolveur. Si ce dernier décide de collecter des données, de mentir, DoH n'y changera rien.
La confiance est donc essentielle. D'autant que tout semble indiquer que les internautes profiteront de cette solution d'une manière assez inhabituelle : dans les navigateurs, tels que Chrome et Firefox. Ces derniers passeront ainsi outre la configuration de la machine pour exploiter DoH via des serveurs tiers de leur choix. Une façon de faire qui pose question.
Un sujet que nous aborderons dans la suite de ce dossier, où nous évoquerons également les méthodes pour activer DoH.
Notre dossier sur DNS over HTTPS :
- Qu'est-ce que DNS over HTTPS (DoH), qu'est-ce que cela peut vous apporter ?
- DNS over HTTPS (DoH) : au-delà de Firefox, une « question de confiance »
- DNS over HTTPS (DoH) : pour Stéphane Bortzmeyer, « le diable est dans les détails »
- Comment activer DNS over HTTPS (DoH) ? (à venir)
