Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Qu'est-ce que DNS over HTTPS (DoH), qu'est-ce que cela peut vous apporter ?

Le retour de l'être aimé ?
Qu'est-ce que DNS over HTTPS (DoH), qu'est-ce que cela peut vous apporter ?
Crédits : zmeel/iStock

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.

DNS
Crédits : TouiTouit, Michel et le hamster (licence: CC by SA 4.0)

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) :

DNS Requête classiqueDNS Requête classique
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 DNSCryptGNUnetDNS 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 :

77 commentaires
Avatar de nitronix INpactien
Avatar de nitronixnitronix- 11/03/20 à 17:28:16

Tres intéressant merci. Vivement la suite.

Avatar de coolman Abonné
Avatar de coolmancoolman- 11/03/20 à 17:32:05

une question cependant : dans la commande "curl -v --doh-url https://dns.quad9.net/dns-query www.gouvernement.fr", il y'a bien une résolution DNS classique de dns.quad9.net qui est effectué ?

Le fournisseur DNS initial est donc au courant qu'on va chez quad9.net.
Même si il ne sait pas que c'est pour aller sur www.gouvernement.fr, cela ne fait t'il pas que déplacer le problème ou apposer un pansement sur une jambe de bois ?

Édité par coolman le 11/03/2020 à 17:33
Avatar de crocodudule INpactien
Avatar de crocodudulecrocodudule- 11/03/20 à 17:44:07

"Quad9 sait ce qui lui a été demandé, par quelle machine"

Est-ce que DoH + proxy ne serait pas la solution?

Le proxy lui ne verra qu'un échange chiffré et à l'inverse le résolver n'aura que l'ip de la machine faisant serveur proxy. Ca pourrait le faire non ?

Avatar de Zone démilitarisée Abonné
Avatar de Zone démilitariséeZone démilitarisée- 11/03/20 à 17:45:59

On dit « la tablette de Michel », non ?

Avatar de crocodudule INpactien
Avatar de crocodudulecrocodudule- 11/03/20 à 17:46:39

coolman a écrit :

une question cependant : dans la commande "curl -v --doh-url https://dns.quad9.net/dns-query www.gouvernement.fr", il y'a bien une résolution DNS classique de dns.quad9.net qui est effectué ?

Le fournisseur DNS initial est donc au courant qu'on va chez quad9.net.      
Même si il ne sait pas que c'est pour aller sur www.gouvernement.fr, cela ne fait t'il pas que déplacer le problème ou apposer un pansement sur une jambe de bois ?

Certes mais est-ce que ça permet d'en déduire quelque chose sur le plan de la vie privée?

Interroger un serveur DNS sans savoir ce qu'on lui a demandé me semble présenter aucun risque, enfin ce n'est que mon sentiment. Le risque c'est que le resolver lui conserve qui lui a demandé quoi pas que ton FAI sache que t'es allé demander des trucs à ce resolver mais sans savoir quoi.

Édité par crocodudule le 11/03/2020 à 17:47
Avatar de Qruby Abonné
Avatar de QrubyQruby- 11/03/20 à 17:49:16

On déplace le tiers de confiance, au risque de le centraliser.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 11/03/20 à 17:57:10

Ton serveur racine, TLD/SLD c'est pas déjà un point de centralisation ? Tu sembles confondre deux soucis : DoH en tant que tel (qui est une technologie intéressante, n'ajoutant pas de centralisation spécifique) et l'implémentation dans les navigateurs (sujet sur lequel on reviendra dans le prochain papier).

Avatar de David_L Équipe
Avatar de David_LDavid_L- 11/03/20 à 18:05:12

coolman a écrit :

une question cependant : dans la commande "curl -v --doh-url https://dns.quad9.net/dns-query www.gouvernement.fr", il y'a bien une résolution DNS classique de dns.quad9.net qui est effectué ?

Le fournisseur DNS initial est donc au courant qu'on va chez quad9.net.
Même si il ne sait pas que c'est pour aller sur www.gouvernement.fr, cela ne fait t'il pas que déplacer le problème ou apposer un pansement sur une jambe de bois ?

Oui, mais ce n'est pas tant un souci puisque tu dévoiles seulement le service utilisé, le même pour l'ensemble des requêtes, pas le contenu de celles-ci. Au pire tu peux encapsuler dans un flux de type VPN par exemple, l'intérêt dans ce cas c'est que DoH permet que le fournisseur de VPN n'ait aucune idée du contenu des requêtes DNS, contrairement à ce qui se fait actuellement. 

Avatar de Quiproquo Abonné
Avatar de QuiproquoQuiproquo- 11/03/20 à 18:59:52

Non, on dit « la main de ma sœur dans la culotte d'un zouave », mais on dit « la tablette à Michel » ou « le frère à mon beau frère ».

Avatar de Cqoicebordel Abonné
Avatar de CqoicebordelCqoicebordel- 11/03/20 à 19:00:49

Le fournisseur initial sait que tu as ouvert l'annuaire, mais ne sait pas ce que tu as cherché :)

Il n'est plus possible de commenter cette actualité.
Page 1 / 8
  • Introduction
  • Le DNS : un élément simple au centre de nombreux enjeux
  • Le besoin de chiffrement du DNS
  • DoH, comment ça marche ?
S'abonner à partir de 3,75 €