Apporter le chiffrement aux DNS est un besoin devenant essentiel. Si DNS over HTTPS participe à cet effort, il faut être attentif à la manière dont cette technologie est mise en œuvre. Un sujet complexe, surtout quand les éditeurs de navigateurs sont à la manœuvre. Même lorsqu'il s'agit de Mozilla.
Nous l'avons vu dans la première partie de ce dossier, le DNS est l'un des rares éléments techniques d'internet, que chacun d'entre nous utilise au quotidien, où la sécurité fait encore trop souvent défaut. Conçu il y a quarante ans, il n'a tout simplement pas été pensé pour bénéficier du chiffrement ou d'une signature de ses données.
Mais peu à peu les choses changent. Outre la mise en place (poussive) de DNSSEC, de nombreuses initiatives voient le jour et sont plus ou moins suivies par les différents acteurs. L'une d'elle est DNS over HTTPS (DoH) qui vise, comme son nom l'indique, à chiffrer les requêtes DNS en les encapsulant dans un flux HTTPS classique.
Une solution malaimée pour son aspect « HTTPisation du Net », mais qui a l'avantage d'être simple à appliquer, de se reposer sur des briques logicielles connues et maitrisées, ne pouvant être facilement bloquées en visant, par exemple, des ports spécifiques (contrairement à DNS over TLS, DoT).
Utiliser un résolveur DoH : pas si simple
Dans notre précédent article, nous avons ainsi montré comment on pouvait effectuer une requête sur un résolveur DNS exploitant DoH à travers une simple ligne de commande. Mais voilà, l'utilisateur n'a que faire de telles solutions : il veut pouvoir profiter de la meilleure sécurité d'un tel résolveur par défaut, sans avoir à se casser la tête.
En l'état actuel des choses, ce n'est pas possible. Des travaux en ce sens sont en cours pour l'intégration aux interfaces des routeurs ou d'OS, notamment Windows 10, mais aucune date précise n'a encore été donnée. C'est pour cela qu'un autre type d'acteur s'est saisi du sujet ces dernières années : les navigateurs.
Car pour ce qui est de votre accès à internet, ils sont en première ligne. Une idée en apparence intéressante, séduisante, mais qui ajoute son lot de questions et de complexités.
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)
Une question de confiance
Car nous l'avons vu : DoH n'est pas un totem d'immunité. Tout d'abord parce qu'il n'est pas utilisé par les serveurs racine, de premier et de second niveau (TLD/SLD). Ainsi, il est impossible de se connecter à ces derniers de manière chiffrée et d'obtenir une réponse l'étant également. Le lien entre un résolveur DoH et eux n'est donc toujours pas sécurisé.
Autre problème : même si l'on s'y connecte à travers une requête HTTPS, un résolveur tiers reste un acteur en qui l'on doit avoir toute confiance. DoH vise à chiffrer le lien entre lui et nous, sécurisant l'échange, rien de plus. Le résolveur a toute connaissance des requêtes qu'un utilisateur effectue et DoH ne l'empêche pas de « mentir » dans ses réponses.
Elles peuvent être chiffrées, mais fausses. Il ne faut donc pas choisir son résolveur à la légère. Si l'on trouve par ici ou par là des listes de services compatibles DoH, il faut donc faire un peu de tri. En voici certains, situés en Europe (donc soumis au RGPD) et gérés par des organismes à but non lucratif :
- https://doh.powerdns.org/
- https://odvr.nic.cz/doh
- https://ldn-fai.net/dns-query
- https://doh.42l.fr/dns-query
- https://dns.hostux.net/dns-query
DoH n'apporte pas de centralisation
Depuis quelques mois, lorsqu'il est question de DNS over HTTPS, les mêmes mots reviennent toujours, presque mécaniquement. Le reproche le plus courant est que cette technologie porte en elle le germe de la centralisation.
C'est pourtant totalement faux : n'importe qui peut installer son propre résolveur DNS compatible DoH au sein de son réseau, l'utiliser pour lui-même, ses proches, le mettre à disposition des autres. C'est d'ailleurs ce qu'a fait Stéphane Bortzmeyer. Nombreux sont ceux qui existent déjà, à travers différents clients, démultipliant les possibilités. Ce, alors que le DNS est lui-même une solution technique qui a ses passages obligés : les serveurs racine, TLD/SLD.
Rappelons au passage qu'utiliser un résolveur DoH présent sur votre réseau local, pour vous-même, n'a que peu d'intérêt. Chiffrer un échange local n'apporte pas un grand bénéfice en matière de sécurité. Par contre, ce résolveur devra contacter lui-même les serveurs racine et TLD/SLD, de manière non chiffrée. Ils sauront alors directement qui est à l'origine de ces requêtes, ces échanges pouvant être observés par des tiers. On en revient au problème évoqué précédemment.
Il peut donc être opportun d'utiliser également un résolveur DoH tiers, ayant de nombreux utilisateurs. Lorsque votre résolveur DNS local ne sera pas suffisant, elle se tournera vers ce serveur externe, de manière sécurisée. C'est lui seul qui apparaîtra pour les serveurs racine et TLD/SLD, vos requêtes étant noyées dans la masse.
Utiliser DoH est donc une bonne chose, cette technologie ayant de nombreux intérêts.
Le cas Firefox
Mais alors, pourquoi parle-t-on de centralisation du fait de DoH ? Cela vient en réalité de son implémentation. Car à défaut de pouvoir être activée dans une majorité de routeurs et d'OS, cette technologie a trouvé refuge dans les navigateurs.
Et en premier lieu Firefox, Mozilla ayant décidé de l'activer par défaut, pour l’instant aux États-Unis. Ailleurs, l'option est présente mais doit être activée manuellement. Autre choix effectué par défaut : utiliser Cloudflare comme résolveur DNS compatible DoH. Ce, alors que l'entreprise est déjà fortement critiquée pour être un SPoF (point de défaillance unique) du web actuel, tant il est utilisé par nombre de sites pour assurer leur sécurité en tant que firewall applicatif (WAF).
Mozilla a expliqué à plusieurs reprises chercher ce type de partenariat. L’éditeur a d'ailleurs créé une charte rassemblant tout un lot de règles sur lesquelles les partenaires doivent s’engager pour avoir le droit de figurer dans Firefox. Notamment, effacer quotidiennement les données accumulées et ne jamais les transmettre à des tiers.
Cette liste de prestataires devrait grandir avec le temps, mais Mozilla n’a pas donné de calendrier. Autre regret : cette solution ne protège pas tous les usages effectués hors du navigateur, et ils sont nombreux.
Pour accéder aux paramètres DoH de Firefox, rendez-vous dans l'onglet Général des options, puis dans les Paramètres réseau
Les utilisateurs ne modifient que très rarement les paramètres par défaut, certains craignent de voir CloudFlare devenir le résolveur DNS du plus grand nombre, un peu comme Google est utilisé comme moteur de recherche par défaut, notamment pour sa place centrale dans de nombreux systèmes et navigateurs (dont Firefox dans la plupart des pays).
Mozilla propose pourtant NextDNS comme alternative pour le moment, proposant même un mode personnalisé où vous pouvez indiquer l'URL du résolveur DNS compatible DoH de votre choix. Ajoutons que pour être certain de pouvoir faire son travail, Firefox utilise son propre résolveur, ainsi qu'un domaine à l'adresse use-application-dns.net.
On pourrait néanmoins imaginer que le navigateur n'impose aucun choix par défaut, propose à l'utilisateur de choisir après l'installation ou modifie régulièrement ce paramètre tant qu'aucun choix n'est fait par exemple. Ce n'est pour l'instant pas le cas. Il faudra d'ailleurs être attentif à l'attitude des navigateurs dérivés de Chromium sur le sujet.
Pour le moment au stade expérimental, le support DoH n'impose rien. Mais Google plaçant déjà ses propres DNS par défaut dans les routeurs Wi-Fi qu'il commercialise, on imagine qu'il sera tenté de faire de même dans Chrome. À suivre.
Commentaires (50)
#1
Quelqu’un a déjà testé Adguard Home ?
" />
https://github.com/AdguardTeam/AdGuardHome
Apparemment, c’est du clé en main. Il fait DoH et DoT en tant que serveur et demandeur de requêtes.
Et pour ceux qui veulent tester avec unbound, j’ai trouvé ce post :https://www.reddit.com/r/Adguard/comments/dkhxsq/how_do_i_setup_unbound_on_adgua…
Il faudra un jour que j’essaie quand j’aurai du temps
#2
“Mais Google plaçant déjà ses propres DNS par défaut dans les routeurs Wi-Fi qu’il commercialise, on imagine qu’il sera tenté de faire de même dans Chrome. À suivre.”
Google force déjà ses propres DNS dans ses Chromecast. Il est impossible de les modifier sauf au travers de très complexes manipulations visant à rooter la Chromecast.
#3
Oui après Chromecast est un outil plus spécifique, contrairement au routeur qui indique aux appareils du réseau quels résolveurs DNS utiliser, et donc à qui envoyer toutes les requêtes. Mais c’est également un problème qu’ils soient modifiés par défaut et non configurable, oui. Même si utiliser Chromecast sans vouloir que Google sache ce que l’on regarde, me paraît un brin étrange…
" />
#4
Perso à la maison c’est Pi-hole + unbound configurés pour faire du DoT, et installé sur un NAS qui est aussi mon serveur DHCP.
Pour le PC du boulot sous Windows j’ai DNSCrypt Client Proxy qui est pas mal et très configurable.
#5
C’est surtout que je pense que forcer les DNS de Google permet de faire du blocage géographique de contenu.
#6
#7
Le chiffrement sur le réseau local, oui ça n’a pas grand intérêt, mais avoir un serveur dns sur son réseau local comme Pi-hole est tout de même utile. Le serveur DNS local peut utiliser DoH / DoT entre lui et les serveurs DNS upstream. Se pose donc la question de la confiance, mais toujours mieux que d’utiliser les DNS non chiffrés du FAI à mon avis.
#8
Oui le DNS local en lui-même a un intérêt, mais pour DoH & co il vaut mieux se reposer sur un serveur tiers (et du coup le résolveur local est un peu moins utile, mais c’est toujours ça de pris). Dans le cas de Pihole & co, il est surtout utilisé pour ses fonctionnalités “annexes” disons (et là le côté menteur ne gêne plus :p)
#9
#10
Oui, si tu passes par des résolveurs tiers en complément de ton résolveur local, comme dit plus haut.
#11
Attention, si tu utilises Unbound en tant que client DoT (qui forwarde donc les requêtes vers un résolveur via TLS), la gestion de TCP par Unbound est quelque peu olé-olé pour ne pas dire à chier (il coupe la connexion TCP après chaque requête, ça plombe les perfs et augmente la charge réseau - il faut refaire la triple poignée de mains TCP et toute la négo TLS à chaque requête, c’est un massacre).
En client, il faut mieux utiliser Stubby :)
#12
Du DoT vers quel résolveur ?
#13
Bonjour, il faudrait arrêter la publicité monsieur, merci
" /> 
" />
#14
Étant sous linux, je suis en train de regarder du côté de firejaildns que je viens juste de découvrir. C’est fait pas ceux qui font la sandbox firejail.
#15
Ça me rappelle tellement les problématiques IMAP/LDAP/….
Petite question, c’est basé comment sur firefox, sur une IP ou sur une URL ? Parce que de ce que je comprends, on va tout de même devoir faire une requête DNS pour pouvoir faire du DOH.
Seconde question est-ce qu’a terme on va donc devoir gérer les DNS de l’OS et les DOH dans le navigateur ? Et du coup pourquoi pas un client DOH dans d’autre applications ?
Troisième question, est-ce qu’il y a une raison technique à ne pas avoir fait du STARTTLS pour DNS ? Ca réponds tout de même au deux problématiques, pas de changement de port et pas de HTTP inutile au milieux.
Y’a quatre choses qui m’embêtent clairement :
#16
Tu peux avoir une IP dans une URL, je dis ça, je dis rien
" />
#17
#18
aureus a écrit :
Seconde question est-ce qu’a terme on va donc devoir gérer les DNS de l’OS et les DOH dans le navigateur ? Et du coup pourquoi pas un client DOH dans d’autre applications ?
Aucune idée, DoH est juste un protocole, comme DoT, comme le DNS classique, il peut être mis dans le système d’exploitation ou bien dans les applications.
#19
#20
#21
#22
Des intérêt s du DNS local c’est:
* filtrage parental
* éviter les DNS menteurs des FAI
* filtrage de pub comme le propose aussihttps://dns.hostux.net/fr/ viahttps://dns.hostux.net/ads
#23
J’imagine que les logiciels malveillants vont vite utiliser DoH pour éviter de se faire repérer.
#24
Le chiffrement, c’est la plaie. Les gens honnêtes qui n’ont rien à cacher ne l’utilisent pas.
#25
C’est un des rares cas où je fais la pub d’autre chose qu’Unbound !
" />
#26
Le géoblocage de contenu se fait plus au niveau de l’IP du client que des DNS utilisés je pense.
#27
J’utilise SimpleDNSCrypt sur Windows, ça permet le DoH en plus du DNSCrypt (mais c’est moins performant donc je l’ai désactivé), configuré au niveau de l’interface réseau et non du navigateur, c’est donc un résolveur local avec cache et gestion de liste noire d’IP ou domaines, de redirections et tout ce qu’on peut vouloir, et ça résout automatiquement désormais parmi les serveurs qu’on autorise. La confiance doit se faire envers cette liste de serveurs et le respect de leur promesse de “pas de log / pas de mensonge”.
#28
Oui, d’où ma remarque ;) On avait eu la demande avec Quad9 dans la précédente actu et j’avais testé que ça fonctionnait par acquis de conscience
" />
#29
Sur un Syno RT1900AC, on peut activer DoH au niveau du DNS du routeur. Par contre on a le choix uniquement entre Cloudflare et Google
Sur des FortiGate, au boulot, on peut faire du DoT.
#30
Je me doute mais vu que je vais vu que des URL dans ton article
" />
#31
Ah oui c’était pas spécifique à DoH, mais à la décision de firefox de mettre un client DNS dans son navigateur.
#32
#33
Merci pour cet article que j’attendais avec impatience. Vous êtes les meilleurs!
#34
Mais Google plaçant déjà ses propres DNS par défaut dans les routeurs
Wi-Fi qu’il commercialise, on imagine qu’il sera tenté de faire de même
dans Chrome.
Ah oui on en est là !!
#35
#36
J’utilise pihole à la maison pour bloquer la pub, les réseaux sociaux, la télémétrie de Windows et autres joyeusetés sites malveillants. Je l’ai configuré pour aller piocher ses entrées DNS chez les meilleurs (FDN évidement). La lecture de cet article m’évoque 2 questions :
Edit: mise en forme
#37
Je suis dans le même cas que toi mais j’ai en plus unbound pour avoir un cache de 48h et DNSSEC avec Quad9 (tutohttps://docs.pi-hole.net/guides/unbound/)
Ne pas oublier sur les firmwares alternatifs des routers (openwrt, Asuswrt-Merlin, freshtomato…) qui proposent du dnscrypt et stubby ou autres.
#38
C’est vraiment une très mauvaise idée.
D’abord, DNS sur HTTP, carton rouge, c’est pas fait pour ça. Pourquoi pas du DHCP ou du BGP sur HTTP tant qu’on y marche sur la tête…
Ensuite, contourner le DNS du système par le navigateur va créer énormément de problèmes vu que les résultats entre le navigateur et les autres logiciels seront potentiellement différents. D’autant plus vrais en entreprise ou la majorité des sites utilisés sont des applis locale accessible grâce au DNS local. Avec un DNS dans le navigateur, toutes les applis locales (ou sur le VPN de la boite) seront inaccessibles.
Il y a pourtant une solution : DNSSEC c’est spécialement conçu pour ça et ça marche bien. Ils sont en train d’inventer une usine à gaz dangereuse juste parce que les opérateurs sont fainéant et n’implémentent pas DNSSEC…
#39
Sauf erreur de ma part, DNSSEC garantie l’intégrité du message DSN (impossibilite de rajouter des lignes ou d’enlever sans casser la signature) alors que DoT ou DoH garantissent la confidentialité de l’échange DNS (personne ne peut lire).
Bref, les deux sont complementaires et ne cherchent pas à résoudre les mêmes problèmes.
#40
Ah tu réponds à une autre de mes questions à savoir comment faire en sorte que le cache DNS reste plus longtemps dans pihole. C’est pas natif à pihole, il faut que j’ajoute unbound donc ? J’irais faire un tour. Après tout les @IP des divers serveurs ne changent pas si souvent que ça.
#41
Oui et c’est l’option cache-max-ttl dans le fichier conf d’unbound (il est au début)
Effectivement 1j c’est suffisant (j’ai de mémoire 1500 url journalier) mais j’avais fait un test avec WSCC qui interroge au moins 200 url et là c’est flagrant comme différence.
Na pas oublier aussi que pi-hole est nullement réservé aux minimachines, il existe une config docker-compose sous les différents OS :https://github.com/pi-hole/docker-pi-hole
#42
Je suis allé lire la page du tuto unbound pour pihole. Pour le moment je ne suis pas sûr d’être intéressé par le fonctionnement d’unbound (je ne saisis pas l’intérêt, comparé à DoH).. Existe-t-il directement dans pihole un moyen d’augmenter le temps de vie des entrées du cache DNS ?
#43
#44
Je viens de tester avec wireshark et firefox et c’est effectivement le cas.
#45
Malgré cette page https://docs.pi-hole.net/ftldns/dns-cache), je n’ai pas trop compris le fonctionnement mais il y a bien un truc.
En tout cas, le DNS cache insertions est raz au boot, il est passé de 3800 (j’avais un uptime de 31 jours) à 0.
#46
Article intéressant et tout mais à quand la suite ?
ce qu’on veux c’est pouvoir l’utiliser, de savoir le comment ça fonctionne c’est bien mais ne permet pas de l’utiliser. Il y a l’extension easydoh pour firefox qui permet de tout configurer facilement.
#47
Ah, merci du tuyau :-) Je vais voir si je peux mettre Stubby au lieu de Unbound.
#48
Vers Quad9
#49
Il y a quoi de compliqué dans la configuration de FF ?
#50
Ici je parlais pour activer DoH sur FF et non configurer FF en général
Pour des advanced user comme l’audience de NXI je pense qu’il n’y rien de compliqué mais pour Mr et Mme
Michu je ne pense pas que cela soit si simple de configurer des fonctions avancées comme DoH ou gestion de la vie privée en personalisée. Surtout que maintenant FF à un blocage des traqueurs intégrés et donc des sites ne fonctionnent plus maintenant car adblocker détecté.