Connexion
Abonnez-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 ?

Le 11 mars 2020 à 17h00

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 :

Le 11 mars 2020 à 17h00

Commentaires (77)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Tres intéressant merci. Vivement la suite.

votre avatar

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 ?

votre avatar

“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 ?

votre avatar

On dit « la tablette de Michel », non ?

votre avatar







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.


votre avatar

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

votre avatar

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

votre avatar







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. 


votre avatar

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 ».

votre avatar

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

votre avatar

Sur un Pi-hole cela fonctionne très bien avec Cloudflared –>https://docs.pi-hole.net/guides/dns-over-https/

:)

 

votre avatar

Bonsoir,



Parallèlement j’ai vu qu’il y a DNS over TLS, ce qui serait directement au niveau OS (je préfère par rapport au navigateur) ; est-ce que quelqu’un sait si c’est un sujet qui avance par exemple pour un support par Windows et les fournisseurs de DNS publics connus ?



Merci

votre avatar

Par contre ça doit parasiter certain contrôle de flux passif qu’on peu trouver sur des UTM comme Fortigate non ?

votre avatar

Le truc, c’est que DoH c’est bien quand on surf depuis un état sous surveillance, mais c’est moins bien quand on surf depuis un pays “libre”.



On se plaint de la centralisation d’Internet, mais quand on a un protocole décentralisé, qui fonctionne parfaitement bien, on invente des technos pour recentraliser ca chez QuadNine ou chez CloudFlare…



Déjà que cloudflare fait transiter la moitier du web par ses serveurs (étude au doigt mouillé, mais l’idée est là) et peut donc savoir ce que vous consultez, maintenant, les quelques boites comme cloudflare, capable d’héberger des serveurs DoH qui sont bien plus gourmand que du DNS classique, vont aussi récupérer le noms des sites qu’ils ne protègent pas. En terme de BigBrother, je crois qu’on tient le vainqueur.



Le bon, c’est qu’on arrêtera de filer nos info à 8.8.8.8…



Bref… Je ne suis franchement pas convaincu par DoH.

votre avatar

<img data-src=" />



Après je vois cela comme une autre possibilité de naviguer sur le web en contournant des limitations ou des restrictions, pas toujours que dans un pays totalitaire.



Cela donne aussi aux navigateurs un moyen de trouver un site web si le DNS est menteur =&gt; popcorn pour les nayansdroits.



Mais tu as raison, si implémenté dans Chrome, on sait que ça va finir sur 8.8.8.8 like ^^

votre avatar

<img data-src=" />

Le seul cas où on peut utiliser « à » (pour l’appartenance, la possession), c’est lorsqu’il est suivi d’un pronom personnel (je, tu, il, elle, etc.) (ou dans une construction verbale).



Donc on dit bien « La tablette de Michel » et « le frère de mon beau frère », mais « sa tablette à lui » et « son frère à elle ».



Edit : +lien

Et sinon, j’ai hâte de lire la suite.

votre avatar

Je ne suis vraiment pas fan de ces résolutions de noms “sauvage” des navigateurs. J’ai découvert cela par hasard, en me demandant pourquoi IE résolvait en utilisant le fichier hosts en premier, mais par FF, Opera ou Chrome.

Au final, on s’aperçoit qu’ils peuvent interroger le DNS qu’ils veulent, pas celui du système (et donc contourner les anciens DNS menteurs qui servaient à faire un “filtre” parental basique).



Je préfèrerais avoir une liste tournante de 10 DNS. Par ailleurs, si nos ordis font des requêtes DNS, est-ce que la BOX ne devrait pas être le cache DNS local pour tous les téléphones/ordis de la maison?

votre avatar







brice.wernet a écrit :



Je préfèrerais avoir une liste tournante de 10 DNS. Par ailleurs, si nos ordis font des requêtes DNS, est-ce que la BOX ne devrait pas être le cache DNS local pour tous les téléphones/ordis de la maison?





Perso je suis sur un router qui supporte nativement DOH, du coup en local c’est en clair, et quand ca quitte de chez moi c’est DOH.



(comme ca mon routeur peut appliqué le safebrowsing, et la détection de menace, sans avoir a resté sur du non chiffré, c’est plus saint que de laissé les logiciels faire du dns dans leur coins …).


votre avatar

DoH ou DoT, si c’est implémenté au niveau de l’OS et pas du navigateur (pas de bypass du fichier hosts, choix du resolveur via conf statique ou via DHCP, …) ca me va, mais il me semble que la rfc 8484 va prendre du temps avant d’être implémentée sur tous les systèmes

votre avatar







ForceRouge a écrit :



Le truc, c’est que DoH c’est bien quand on surf depuis un état sous surveillance, mais c’est moins bien quand on surf depuis un pays “libre”.



On se plaint de la centralisation d’Internet, mais quand on a un protocole décentralisé, qui fonctionne parfaitement bien, on invente des technos pour recentraliser ca chez QuadNine ou chez CloudFlare…



Déjà que cloudflare fait transiter la moitier du web par ses serveurs (étude au doigt mouillé, mais l’idée est là) et peut donc savoir ce que vous consultez, maintenant, les quelques boites comme cloudflare, capable d’héberger des serveurs DoH qui sont bien plus gourmand que du DNS classique, vont aussi récupérer le noms des sites qu’ils ne protègent pas. En terme de BigBrother, je crois qu’on tient le vainqueur.



Le bon, c’est qu’on arrêtera de filer nos info à 8.8.8.8…



Bref… Je ne suis franchement pas convaincu par DoH.





Comme dit plus haut, il ne faut pas tout mélanger. DoH ne recentralise rien. On utilise un résolveur DoH ou pas, n’importe qui peut mettre en place une solution DoH, il n’y a pas que Cloudflare & co. Les choix faits par certains navigateurs pour le moment peuvent par contre poser problème.





brice.wernet a écrit :



Je ne suis vraiment pas fan de ces résolutions de noms “sauvage” des navigateurs. J’ai découvert cela par hasard, en me demandant pourquoi IE résolvait en utilisant le fichier hosts en premier, mais par FF, Opera ou Chrome.

Au final, on s’aperçoit qu’ils peuvent interroger le DNS qu’ils veulent, pas celui du système (et donc contourner les anciens DNS menteurs qui servaient à faire un “filtre” parental basique).



Je préfèrerais avoir une liste tournante de 10 DNS. Par ailleurs, si nos ordis font des requêtes DNS, est-ce que la BOX ne devrait pas être le cache DNS local pour tous les téléphones/ordis de la maison?





Un logiciel peut toujours faire ce qu’il veut. Après sur le fond, le problème existe déjà. Par exemple avec les routeurs Google/Next Wifi qui utilisent toujours 8.8.8.8 par défaut…&nbsp;

&nbsp;



TiboodiT a écrit :



DoH ou DoT, si c’est implémenté au niveau de l’OS et pas du navigateur (pas de bypass du fichier hosts, choix du resolveur via conf statique ou via DHCP, …) ca me va, mais il me semble que la rfc 8484 va prendre du temps avant d’être implémentée sur tous les systèmes





Oui, ça prendra du temps et c’est pour ça que le choix a été fait par les navigateurs de l’implémenter en direct. Surtout qu’on passe de “il faut indiquer une IP qu’on récupère par DHCP” à “Il faut indiquer une URL”, sans liste publique existante. Cela change pas mal de chose dans le fonctionnement des piles réseau des OS donc ça va prendre un peu de temps, en effet.


votre avatar

Est-ce que ça peut s’implémenter en auto hébergé ?

votre avatar

Oui tu as des résolveurs DNS qui gèrent nativement DoH (donc cache local puis sinon un serveur distant avec chiffrement). J’essaierai de détailler ça dans la partie activation <img data-src=" />

votre avatar







Macarie a écrit :



(comme ca mon routeur peut appliqué le safebrowsing, et la détection de menace, sans avoir a resté sur du non chiffré, c’est plus saint que de laissé les logiciels faire du dns dans leur coins …).&nbsp;



J’avais fait un point d’accès Wifi pour les enfants, le plus dur était de détourner le DNS vers le mien (qui ne répondait pas bien à certaines requêtes , le porno et les pubs), mais les tablettes allaient taper directement sur d’autres DNS –&gt; il fallait vraiment détourner tout le flux du port 53, pas seulement répondre aux requêtes DNS.


votre avatar

Et une bouse protocolaire de plus à ajouter au tableau de chasse de ceux qui ne savent pas penser autrement qu’au travers de HTTP -.-

votre avatar

L’histoire des nouvelles technologies est pleine de solution parfaites mais utilisées par personne ;)&nbsp;

votre avatar

  • Microsoft a déclaré vouloir implémenter DoH dans Windows et DoT peut-être un jour



    • DoT est disponible nativement sous Android depuis la version 9

    • Sous Linux, systemd-resolved le gère, mais bon y a mieux a côté :)

    • Chez Apple, aucune idée


votre avatar







L’article a écrit :



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.



Ce n’est pas ça le pb ! avec DNS over HTTPS c’est exactement la même chose. (Cloudfare a exactement les même infos qu le résolveur DNS classique)

Le pb est que le traffic en DNS standard est en clair, n’importe qui peut (FAI, gars branché sur le même réseau filaire ou wifi) voir les résolutions DNS transiter en clair, avant que les connexions ne soient éventuellement chiffrée via HTTPS.

Avec DoH le résolveur DNS connait toujours la liste des noms résolus, par contre les intermédiaires (FAI, autres PC en réseau local) ne voient rien du tout car la résolution des noms passent dans un tuyau HTTPS chiffrés.


votre avatar

Le but est justement de bloquer ce genre de logiciel malveillant

votre avatar

Idéalement, il faudrait utiliser DoT, mais il est trivial a bloquer puisqu’il passe par un port dédié (853 par défaut). En France, on peut facilement tester ce blocage sur les accès Wi-Fi des TGV me semble-t-il (le port 53 est bloqué, et 853 aussi de ce que j’ai compris)



Le port 443 en revanche est quasi impossible a bloquer. Et l’encapsulation de la requête DNS dans une requête HTTP ne rend pas le trafic suspect



Alors oui, c’est une étape de plus vers Internet-over-HTTPS, mais en l’état pas d’autres choix.



Et par ailleurs, il faut considérer DoH comme un dernier recours (si DoT est bloqué, on passe sur DoH). Le hic étant que le protocole est utilisé n’importe comment (implémenter ça dans les applications type navigateur). Il y a un risque qu’à terme tous les logiciels et bidules connectés utilisent leur propre mécanisme de résolution DNS.

votre avatar

Deux solutions : 1) ignorer le problème car ce n’est pas la même chose que de dire qu’on utilise tel ou tel résolveur, que de dire qu’on visite pornhub.com ou alcooloques-anonymes.org 2) Mettre l’adresse de Quad9 au lieu de son nom.

votre avatar







Quiproquo a écrit :



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 ».



“La tablette de Michel” et “le frère de mon beau frère” sont valides… Le “à” est au pire totalement incorrect, au mieux assez dégueulasse à la prononciation.

Par contre oui on va faire sa fête à Quiproquo <img data-src=" />


votre avatar

Faire du DoH au dessus de Tor serait plus simple et donnerait le même résultat.

votre avatar

D’abord, il est tout à fait faux, comme on le lit souvent, que DoT (DNS sur TLS) serait « dans l’OS » alors que DoH (DNS sur HTTPS) serait « dans le navigateur ». Les deux techniques (et le DNS classique) peuvent parfaitement être déployées dans l’OS ou dans l’application. Zéro différence entre DoT et DoH sur ce point.https://www.bortzmeyer.org/doh-et-ses-adversaires.html



Ensuite, DoT est déployé, la plupart des résolveurs DoH acceptent également DoT, Android a DoT en standard depuis une ou deux versions, etc. Chacun peut choisir.

votre avatar

Rien à voir avec DoH qui n’est après tout qu’un protocole. Quand la moitié du courrier électronique file chez Gmail, est-ce qu’on dit que SMTP est « centralisé ».



DoH n’implique pas du tout d’aller chez CloudFlare. L’article donne d’ailleurs une liste de résolveurs DoH. J’y ajoute le mien, pendant qu’on y est, cf.https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html

votre avatar







Stéphane Bortzmeyer a écrit :



D’abord, il est tout à fait faux, comme on le lit souvent, que DoT (DNS sur TLS) serait « dans l’OS » alors que DoH (DNS sur HTTPS) serait « dans le navigateur ». Les deux techniques (et le DNS classique) peuvent parfaitement être déployées dans l’OS ou dans l’application. Zéro différence entre DoT et DoH sur ce point.https://www.bortzmeyer.org/doh-et-ses-adversaires.html



Ensuite, DoT est déployé, la plupart des résolveurs DoH acceptent également DoT, Android a DoT en standard depuis une ou deux versions, etc. Chacun peut choisir.











John Shaft a écrit :





  • Microsoft a déclaré vouloir implémenter DoH dans Windows et DoT peut-être un jour



    • DoT est disponible nativement sous Android depuis la version 9

    • Sous Linux, systemd-resolved le gère, mais bon y a mieux a côté :)

    • Chez Apple, aucune idée









      Merci des infos, je suivrai donc pour voir si Windows implémente l’un ou l’autre ou les 2 (DoH et DoT).



votre avatar

Sans problème, un exemple avec mon résolveur personnel :https://www.bortzmeyer.org/doh-mon-resolveur.html

votre avatar

Il n’y a pas le choix : dans beaucoup d’endroits (notamment les hotspots Wifi d’hôtels ou d’aéroports), seuls 80 et 443 passent. Tout sur HTTPS n ‘est pas un choix, c’est une obligation.

votre avatar







John Shaft a écrit :



Idéalement, il faudrait utiliser DoT, mais il est trivial a bloquer puisqu’il passe par un port dédié (853 par défaut). En France, on peut facilement tester ce blocage sur les accès Wi-Fi des TGV me semble-t-il (le port 53 est bloqué, et 853 aussi de ce que j’ai compris)



Le port 443 en revanche est quasi impossible a bloquer. Et l’encapsulation de la requête DNS dans une requête HTTP ne rend pas le trafic suspect



Alors oui, c’est une étape de plus vers Internet-over-HTTPS, mais en l’état pas d’autres choix.



Et par ailleurs, il faut considérer DoH comme un dernier recours (si DoT est bloqué, on passe sur DoH). Le hic étant que le protocole est utilisé n’importe comment (implémenter ça dans les applications type navigateur). Il y a un risque qu’à terme tous les logiciels et bidules connectés utilisent leur propre mécanisme de résolution DNS.





Tout ça à cause du non respect de la neutralité du net… <img data-src=" />


votre avatar







fofo9012 a écrit :



Ce n’est pas ça le pb ! avec DNS over HTTPS c’est exactement la même chose. (Cloudfare a exactement les même infos qu le résolveur DNS classique)

Le pb est que le traffic en DNS standard est en clair, n’importe qui peut (FAI, gars branché sur le même réseau filaire ou wifi) voir les résolutions DNS transiter en clair, avant que les connexions ne soient éventuellement chiffrée via HTTPS.

Avec DoH le résolveur DNS connait toujours la liste des noms résolus, par contre les intermédiaires (FAI, autres PC en réseau local) ne voient rien du tout car la résolution des noms passent dans un tuyau HTTPS chiffrés.





Oui, comme on le dit d’ailleurs très bien dans l’article (mais il ne faut pas lire que le début <img data-src=" />)


votre avatar







John Shaft a écrit :



Idéalement, il faudrait utiliser DoT, mais il est trivial a bloquer puisqu’il passe par un port dédié (853 par défaut). En France, on peut facilement tester ce blocage sur les accès Wi-Fi des TGV me semble-t-il (le port 53 est bloqué, et 853 aussi de ce que j’ai compris)



Le port 443 en revanche est quasi impossible a bloquer. Et l’encapsulation de la requête DNS dans une requête HTTP ne rend pas le trafic suspect&nbsp;





On va moins rigoler quand on va commencer à avoir des blocages du type “tout le traffic 443 vers tel ou tel domaine” <img data-src=" />


votre avatar

Après, tu peux aller encore plus loin. Par exemple, en utilisant un routeur OPNsense, via DNS Unbound (DNS over TLS dans ce cas) et ensuite en montant ton propre serveur DNS sécurisé (sur un serveur dédié par exemple).

votre avatar

Là, on fera du SNI chiffré, du domain fronting… La lutte de l’épée et de la cuirasse est éternelle.

votre avatar

<img data-src=" />



“le truc à Machin” <img data-src=" /> <img data-src=" />

votre avatar

Oui d’ailleurs SNI est aussi poussé pas mal en marge de DoH, ce qui est plutôt une bonne chose.

votre avatar



Sympa cet article Merci

<img data-src=" />

Et gros bonus : on apprend plein de trucs en lisant les commentaires

<img data-src=" />

votre avatar







Fab’z a écrit :



Par contre ça doit parasiter certain contrôle de flux passif qu’on peu trouver sur des UTM comme Fortigate non ?





En fait non. Les UTM en entreprise déchiffrent le SSL et le resignent avec un certificat émis depuis une autorité de certificat interne, installée et déployée de manière sécurisée. Ca falsifie les certificats, c’est mal, mais c’est aujourd’hui le seul moyen contre le SSL en toute sécurité.


votre avatar

Quand j’avais activé la fonctionnalité sous Firefox avec mon VPN, cela exposait mon IP réel (DNSLeak). Je ne sais pas si c’est mon client VPN qui a un problème ou Firefox mais en tout cas maintenant je me méfie de ce genre d’implémentation.&nbsp;

votre avatar

Donc pour réusumer, il n’y a pas (encore) de solution parfaite ?

votre avatar







Stéphane Bortzmeyer a écrit :



Faire du DoH au dessus de Tor serait plus simple et donnerait le même résultat.





Sauf erreur dans ce cas Tor est utilisé comme un proxy dans cet usage.


votre avatar

Merci pour le chouette article assez compréhensible pour ma part <img data-src=" />

Pour la partie menteur, le protocole ne pourrait-il pas interroger plusieurs résolveurs, et comparer les résultats ? En cas de divergences, il y aurait un message d’erreur à l’utilisateur lui demandant de choisir quelle IP (en récupérant le titre de page par exemple).

Ça ne solutionne évidemment pas les soucis point de vue vie privée, mais en termes de contournement et de résilience, ça ne me paraîtrait pas déconné ?

votre avatar

En sécurité, il n’y a JAMAIS de solution parfaite.

votre avatar

Ça aggrave même les problèmes de vie privée, en envoyant la requête à davantage de monde.



Si le but est juste de savoir quelle est la bonne réponse, DNSSEC me parait une approche préférable.

votre avatar

On utilise “de” dès lors qu’ une personne est évoquée “de” suite.

“à” c’ est plutôt pour parler d’ un objet comme dans le cas “le balai à chiotte”.

On ne peut pas l’ utiliser autrement à moins de vouloir donner à une personne la valeur d’ un objet tel celui d’ un balai à chiottes.

Fin du troll.

votre avatar

Quel est l’apport de DNSSEC (je ne connais pas bien le domaine des DNS) par rapport à savoir quelle est la bonne réponse ?

(Mais oui, j’imagine bien que ça serait envoyer les infos à plus de monde et donc augmenterait les risques d’écoute)

votre avatar

DNSSEC signe cryptographiquement les données, et le résolveur peut donc facilement vérifier que la donnée est correcte.

votre avatar

Merci pour les précisions <img data-src=" />

votre avatar







Stéphane Bortzmeyer a écrit :



DNSSEC signe cryptographiquement les données, et le résolveur peut donc facilement vérifier que la donnée est correcte.





si j’ai bien compris, dnssec ne permet que de vérifier que la réponse de celui à qui on a demandé la résolution n’a pas été altérée sur le chemin du retour, ça permet pas de s’assurer de la “véracité” de la résolution (du moins par rapport à ce que demande Loufute, si on interroge un dns “menteur”, dnssec apporte quoi dans la “certitude” que la résolution est correcte ?)


votre avatar

Non, ce n’est pas exact. DNSSEC est de bout en bout, puisque la signature est faite par le serveur maitre. (Sur .fr, c’est même un maitre caché, sans accès public depuis l’Internet, donc plus difficile à pirater.) Donc, rien à voir avec « celui à qui on a demandé la résolution ».&nbsp;



Quant aux résolveurs menteurs, DNSSEC ne supprime pas la nécessité d’avoir un résolveur de confiance (soit sur son réseau local, ce qui est quand même recommandé, soit distant et sécurisé par DoT ou DoH.)

votre avatar







Demilitarized Zone a écrit :



On dit «&nbsp;la tablette de Michel&nbsp;», non ?





Oui


votre avatar

Il y a un usage humoristique bien établi, mais évidemment tout le monde n’y est pas sensible. <img data-src=" />

votre avatar







David_L a écrit :



Oui tu as des résolveurs DNS qui gèrent nativement DoH (donc cache local puis sinon un serveur distant avec chiffrement). J’essaierai de détailler ça dans la partie activation <img data-src=" />









Stéphane Bortzmeyer a écrit :



Sans problème, un exemple avec mon résolveur personnel :https://www.bortzmeyer.org/doh-mon-resolveur.html







Merci ! <img data-src=" />


votre avatar

Perso, j’ai déjà testé plusieurs fois le Net chinois, je suis préparé :P

votre avatar

Je réponds plus sérieusement mais toujours pour causer de la Chine, ils n’ont a priori pas bloqué le silo DoH de CloudFlare utilisé par Mozilla pour l’instant, selon les mesures que j’ai pu faire avec un résolveur local. Le hic étant que la fiabilité de la mesure est aléatoire vu qu’idéalement il faut faire la requête depuis un accès Internet chinois, or la j’interroge depuis la France un résolveur ouvert sur place (à environ 300 bornes de Wuhan <img data-src=" />)



Donc a priori, la technique chinoise c’est : OSEF de DoH, on a d’autres méthodes de blocage. Je suis très curieux de voir si eSNI va avoir un impact sur la censure là-bas (je pense pas, mais sait-on jamais, à la marge peut-être).



Je testerai la prochaine fois que j’y vais (histoire de se préparer à ce qui nous attends) <img data-src=" />

votre avatar







Stéphane Bortzmeyer a écrit :



Rien à voir avec DoH qui n’est après tout qu’un protocole. Quand la moitié du courrier électronique file chez Gmail, est-ce qu’on dit que SMTP est « centralisé ».



DoH n’implique pas du tout d’aller chez CloudFlare. L’article donne d’ailleurs une liste de résolveurs DoH. J’y ajoute le mien, pendant qu’on y est, cf.https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html







Je sais bien que ce n’est qu’un protocole, mais j’essaye d’apporter mon analyse au delà de la théorie. Dans la pratique, comme je le dis dans la seconde partie de mon commentaire, seul des boites avec des moyens pourront héberger des vrais serveurs DoH. Dans mon cas, j’ai monté un serveur Knot qui arrive à servir quasiment 1.000.000 requêtes/s. Avec DoH, la “session” http (bien que moins impactant en http/3 sur quic), ainsi que la négo TLS, je doute que je tienne, ne serait-ce que 10% de ce que j’ai fait avec Knot en UDP. Garder un serveur DoH résilient au DOS/DDOS, ca va être vachement plus compliqué, donc restreint à des CloudFlare, Google etc… . La simplicité, aujourd’hui, fait que DNS reste quand même très largement distribué.



Le truc drole, c’est que une fois taper le resolveur DoH, actuellement, ce dernier interroge les serveurs dns UDP classique. Donc concrêtement, ca sert à protéger les gens contre l’espionnage entre son PC et l’un des 3 ou 4 gros capables d’héberger du DoH résilient… Ces mêmes gens qui sont donc espionné par ces même gros.

Je vais me répéter, mais au lieu donc de vouloir accélérer la centralisation des serveurs DNS, on ferait mieux de redescendre les résolveur au plus près des gens.



Ma vision utopique du DNS, c’est qu’il y ai un résolveur directement dans l’OS qui serait capable de faire la récursion de façon autonome.


votre avatar

La question sur le fond, ce n’est pas plutôt : à quand la possibilité d’interroger les serveurs racine, TLD/SLD directement via DoH, DoT ou autre ?&nbsp;



Parce qu’on peut faire toutes les modifications sur un résolveur ou un autre, en bout de chaîne, la centralisation existe, elle est déjà là, et la couche de sécurité en est encore dramatiquement absente. Mais je pense que Stéphane répondra plus complètement que moi sur le sujet <img data-src=" />

votre avatar







David_L a écrit :



La question sur le fond, ce n’est pas plutôt : à quand la possibilité d’interroger les serveurs racine, TLD/SLD directement via DoH, DoT ou autre ? 



Parce qu’on peut faire toutes les modifications sur un résolveur ou un autre, en bout de chaîne, la centralisation existe, elle est déjà là, et la couche de sécurité en est encore dramatiquement absente. Mais je pense que Stéphane répondra plus complètement que moi sur le sujet <img data-src=" />







Je suis d’accord, in fine, la question revient bien à: “à quand la possibilité d’interroger les serveurs racine, TLD/SLD directement via DoH, DoT ou autre ?”. Comme ça je pourrais mettre mon résolveur DoH perso et non centralisé.



Pourquoi ce n’est pas déjà le cas? Ça ne reste toujours que mon avis, mais je pense qu’il y a une part de problème lié à la perf (http/3, TLS) et les DDOS sur les roto DNS qui semblent très fréquents.



Concernant la centralisation de DNS, c’est aussi une autre de mes utopies est de voir une racine alternative sérieuse (je sais qu’il y en a, mais rien qui ne prend de l’ampleur) pour contrer les magouilles et dérives sur l’actuelle comme la vente du .Org.



D’ailleurs, ca serait cool si vous pouviez faire un article en collaboration avec notre gourou national du DNS Stéphane Bortzmeyer sur des questions du genre:




  • Est ce que tout l’argent gagné a créer des tld “à la con” sert uniquement les intérêts de l’IANA?

  • L’argent suffit t’elle à ce que l’IANA reste indépendante? L’est elle vraiment?

  • Qui prend / Comment on été prisent les décisions de créer des nouveaux TLD?

  • Concernant le .Org, comment est-ce possible qu’une société se soit approprié et se donne le droit de vendre un bien commun datant du début de l’Internet?


votre avatar







Demilitarized Zone a écrit :



On dit « la tablette de Michel », non ?







Non, on dit SA tablette à Miche.


votre avatar

Pour les DNS, on peut utiliser pi-hole (DNS + DHCP) + unbound (configuré pour le DoT ou DoH comme DNS upstream pour Pi-Hole), et mettre le tout sur un NAS ou autre serveur local. Ainsi on a un bloqueur de pubs au niveau du réseau.



Sinon, sur un PC on peut aussi par exemple utiliser “DNSCrypt client proxy” qui permet de mettre en place simplement une configuration sécurisée pour tout le système. La configuration est assez simple (fichier texte dnscrypt-proxy.toml). Il est même possible de le lancer automatiquement comme service Windows.

votre avatar

Sur la résistance aux dDoS, j’ai des doutes sérieux : UDP est au contraire bien plus vulnérable, puisqu’il n’y a aucune authentification, même minimale, de l’adresse IP source.



Sur le résolveur local, cela n’a rien d’utopique, c’est assez facile à faire et des tas de gens le font.

votre avatar

&nbsp; « à quand la possibilité d’interroger les serveurs racine, TLD/SLD directement via DoH, DoT ou autre ? »



On y&nbsp; travaille (dans le groupe de travail DPRIVE de l’IETF) et des expérimentations existent (les serveurs faisant autorité pour facebook.com répondent déjà en DoT). L’authentifictaion n’est pas triviale car un client d’un résolveur ne parle qu’à deux ou trois résolveurs, mais un résolveur parle à des milliers de serveurs faisant autorité. Les solutions d’authentification évidentes utilisent le DNS mais on a alors un problème d’œuf et de poule. Mais on avance.

votre avatar

« voir une racine alternative sérieuse (je sais qu’il y en a, mais rien qui ne prend de l’ampleur) »



Le problème des racines alternatives n’est pas technique (monter une racine simple est très facile, cf. le projet Yetihttps://www.afnic.fr/fr/ressources/blog/le-projet-yeti-d-experimentation-d-une-r… monter une vraie racine de production est évidemment plus difficile mais on sait faire). Il est 100 % politique : qui va la diriger ? Les russes ? Les chinois ? Google ? Facebook ? Moi (je veux bien devenir Dictateur en Chef de l’Internet Mondial) ?



Qu’on ne me dise pas qu’il faut qu’elle soit gérée démocratiquement par les utilisateurs. Quand c’est trois types dans leur garage, ça va. Mais à l’échelle mondiale ?

votre avatar

« Est ce que tout l’argent gagné a créer des tld “à la con” sert uniquement les intérêts de l’IANA? »



Une bonne partie de la motivation pour cet argent est juridique. L’ICANN étant une boîte privée, elle ne bénéficie pas de l’impunité juridique dont jouit, par exemple, un gouvernement ou une organisation internationale. Le système juridique étatsunien étant propice aux DoS, il faut être gros pour tenir le coup.



&nbsp;

votre avatar

« - L’argent suffit t’elle à ce que l’IANA reste indépendante? L’est elle vraiment? »



L’indépendance est une notion complexe. Indépendant de qui ? La gestion de la racine n’est pas vraiment indépendante du gouvernement des États-Unis, qui continue à déléguer son fonctionnement à Verisign. Quant à l’ICANN, indépendante du gouvernement des États-Unis ne signifie pas indépendante de la vision états-unienne du monde (aux réunions ICANN, une bonne partie de la soi-disant diversité, les gens qui prétendent représenter l’Afrique, par exemple, sont des gens qui vivent et travaillent aux USA depuis 30 ans…). Et l’ICANN est très marquée par l’idéologie capitaliste (cf. la vente de .org).



&nbsp;

votre avatar

« - Qui prend / Comment on été prisent les décisions de créer des nouveaux TLD? »



Deux cas, les TLD ICANN et les autres.



Pour les TLD ICANN, c’est l’ICANN. Le mécanisme, long, compliqué et cher, est certes très contestable mais,à la décharge de l’ICANN, il faut préciser que personne n’a encore trouvé un mécanisme correct (les idées sont les bienvenues mais le problème est vraiment très difficile ; pensez par exemple au .ISLAM, à qui l’attribuer ?).



Pour les TLD autres, ils dépendent d’un pays. La création de .SS était automatique à l’indépendance du Soudan du Sud. La suppression dépend du bon vouloir du pays (cf. le feuilleton du .SU, qui se porte toujours bien, 28 ans après la fin de l’Union Soviétique). Il reste les cas difficiles comme .EH mais ceux-ci sont difficiles de toute façon. Là encore, personne n’a de solution miracle pour résoudre ces problèmes.

votre avatar

« - Concernant le .Org, comment est-ce possible qu’une société se soit approprié et se donne le droit de vendre un bien commun datant du début de l’Internet?&nbsp; »



Je suis d’accord, c’est scandaleux.

votre avatar

Ouahou, merci pour toutes ces réponses hautement intéressante, ca explique pas mal de décisions qui sont prises. Il faudrait écrire un livre sur la politique interne et la gouvernance du DNS!



Juste sur une des réponses, quand je parlais de “qui décide de créer les tld à la con”, je parlais plus des .car .business .travel , etc… Si j’ai envi de créer mon .forcerouge, c’est possible? Je fais un chèque et hop ?



Merci encore :)



!mode pression=on!

NXI, n’oubliez pas l’article :)

!mode pression=off!

votre avatar

Comme je disais, c’est long, compliqué et cher.



Il n’y a pas d’ouverture en ce moment, on parle d’un prochain cycle de candidatures en 2021 ou 2022. Prix pas encore connu. Attention, les frais de dossier ne sont qu’une petite partie de ce qu’il faut payer.

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

  • Le DNS : un élément simple au centre de nombreux enjeux

  • Le besoin de chiffrement du DNS

  • DoH, comment ça marche ?

Fermer