Dns-over-Https : Pourquoi le DoH n’est pas une bonne solution pour crypter les requêtes DNS

L’ouverture a été l’une des caractéristiques d’internet depuis qu’il existe, une grande partie du trafic passant encore aujourd’hui sans aucune forme de cryptage. La plupart des demandes de pages HTML et de contenu associé sont en texte clair, et les réponses sont renvoyées de la même manière, même si le HTTPS existe depuis 1994.

Mais il y a parfois un besoin de sécurité et de confidentialité. Si le cryptage du trafic internet s’est généralisé pour les opérations bancaires et les achats en ligne, la préservation de la vie privée de nombreux protocoles internet n’a pas suivi le rythme. En particulier, lorsque vous recherchez l’adresse IP d’un site web par nom d’hôte, la requête DNS est presque toujours transmise en texte clair, ce qui permet à tous les ordinateurs et fournisseurs d’accès internet de déterminer le site web que vous avez consulté, même si vous utilisez le protocole HTTPS une fois la connexion établie.

(Voir aussi : Comment contourner les méthodes de sécurité ou de censure)

Le protocole de base de résolution de noms du DNS a toujours fonctionné en mode totalement non crypté, de sorte que les requêtes et les réponses sont accessibles à toute partie qui peut voir ces transactions. Le protocole filaire n’a pas d’authentification, de sorte qu’un opérateur de réseau peut intercepter des requêtes DNS adressées à n’importe quelle adresse IP et fournir une réponse en leur nom. Chaque transaction sur internet commence par une requête de résolution de nom DNS.

Le DNS est un indicateur opportun et précis de tout ce que nous faisons en ligne, et c’est un protocole entièrement non protégé et ouvert. Un véritable champ de mines à ciel ouvert ! Il n’est donc pas étonnant que de nombreux opérateurs de services et de nombreuses entreprises utilisent le DNS à toutes sortes de fins, tant pour la surveillance que pour le contrôle d’accès.

L’idée de crypter les requêtes DNS n’est pas vraiment nouvelle, les premières tentatives ayant débuté au début des années 2000 sous la forme de DNSCrypt, de DNS over TLS (DoT), et d’autres. Mozilla, Google et quelques autres grandes entreprises d’internet proposent une nouvelle méthode de cryptage des requêtes DNS : DNS over HTTPS (DoH).

DNS over HTTPS

Le DoH ne se contente pas de crypter la requête DNS, mais la transmet également à un serveur web « normal » plutôt qu’à un serveur DNS, ce qui rend le trafic de la requête DNS essentiellement indiscernable du HTTPS normal. C’est une arme à double tranchant. Si elle protège la requête DNS elle-même, comme le font DNSCrypt ou DoT, elle rend également impossible pour les responsables de la sécurité des grandes entreprises de surveiller l’usurpation du DNS et elle déplace la responsabilité d’une fonction réseau critique du système d’exploitation vers une application. Il ne fait rien non plus pour cacher l’adresse IP du site web que vous venez de consulter.

Par rapport au DoT, le DoH centralise les informations de votre navigation dans les mains de quelques entreprises : actuellement, Cloudflare, qui affirme ne conserver vos données que durant 24 heures, et Google, qui semble vouloir conserver et monétiser chaque détail de ce que vous faîtes.

Le DNS et la protection de la vie privée sont des sujets importants, c’est pourquoi nous allons entrer ici dans les détails.

Noms de serveurs et confiance

Le concept du système de noms de domaine remonte à l’époque d’ARPANET, où un seul fichier texte sur chaque nœud d’ARPANET contenait la correspondance entre le nom du système et son adresse numérique. Lorsque vous écriviez vous-même ce fichier, il était facile de s’assurer qu’il était correct. Avec la croissance du réseau, il est devenu irréaliste de conserver les copies centrales et locales de ce fichier. Au début des années 1980, des efforts ont été entrepris pour créer un système permettant d’automatiser ce processus.

Le premier serveur de noms DNS (Berkeley Internet Name Domain Server, ou BIND) a été écrit en 1984 par un groupe d’étudiants de l’université de Berkeley, sur la base des RFC 882 et RFC 883. En 1987, la norme DNS a été révisée à plusieurs reprises, ce qui a donné lieu aux RFC 1034 et RFC 1035 qui sont restées largement inchangées depuis lors.

La structure essentielle du DNS est celle d’une configuration arborescente, avec des nœuds et des feuilles subdivisés en zones. La zone racine du DNS est la zone de niveau supérieur, qui se compose de 13 grappes de serveurs racine qui forment les serveurs racine du DNS. Tout serveur DNS nouvellement mis en place (par exemple chez un fournisseur d’accès internet ou dans une entreprise) finira par obtenir ses enregistrements DNS par un de ces serveurs.

Chaque zone DNS supplémentaire ajoute un domaine supplémentaire au système de noms. Chaque pays tend à gérer ses propres domaines, avec des domaines spéciaux (.org, .com, .net, etc.) qui ne sont pas liés à un pays spécifique et qui sont gérés par une entité distincte. Lors de la résolution d’un nom de domaine à l’aide du DNS, il faut commencer par le nom de domaine (par exemple .com), puis le nom (par exemple « google ») et enfin les sous-domaines éventuels. Cela peut impliquer quelques déplacements dans les zones DNS si les données demandées n’ont pas déjà été mises en cache.

DNSSEC : ajouter la confiance aux DNS

Avant de chiffrer les requêtes DNS, il est important de s’assurer que le serveur DNS duquel nous parlons est fiable. Cette nécessité est devenue évidente au cours des années 1990, ce qui a abouti à la première norme opérationnelle d’extension de sécurité DNS (DNSSEC) (RFC 2353) et à la RFC 4033 révisée.

La norme DNSSEC fonctionne en signant les enregistrements de consultation DNS avec une cryptographie à clé publique. L’authenticité d’un enregistrement DNS peut être vérifiée par les clés publiques de la zone racine du DNS. Les propriétaires de domaines génèrent leurs propres clés, qui sont signées par l’opérateur de la zone et ajoutées au DNS.

Bien que le DNSSEC permette d’être relativement certain que les réponses que l’on obtient du résolveur DNS sont authentiques, il exige d’être activé dans votre système d’exploitation. Malheureusement, peu de systèmes d’exploitation mettent en œuvre un service DNS qui ne se limite pas à une simple « prise en compte du DNSSEC », ce qui signifie qu’ils ne valident pas réellement les réponses DNS. Par conséquent, aujourd’hui, on ne peut pas être sûr que les réponses DNS que l’on reçoit soient authentiques.

Le problème avec DoH

Imaginons que vous utilisiez le DNSSEC. Vous êtes maintenant prêt à crypter la communication pour ajouter un niveau de confidentialité à la transaction. Il existe un certain nombre de raisons pour garder ses requêtes DNS à l’abri des regards indiscrets. Parmi les raisons les plus innocentes, on peut citer le fait d’éviter les filtres des entreprises et des fournisseurs d’accès internet, empêcher le suivi de ses habitudes sur internet, etc. Parmi les raisons plus sérieuses, on peut citer le fait d’éviter les persécutions politiques pour avoir exprimé ses opinions sur internet. Naturellement, le cryptage des requêtes DNS empêche les gens d’espionner ces requêtes, mais cela permet aussi d’ignorer la plupart des problèmes de sécurité importants liés au DNS et à tous les autres protocoles de communication.

Les principaux rivaux sont le DoT, qui utilise le TLS, et le DoH qui utilise le HTTPS. La différence la plus évidente entre les deux est le port sur lequel ils fonctionnent : DoT a un port dédié, TCP 853, tandis que DoH se mélange avec les autres trafics HTTPS sur le port 443. Cela présente l’avantage discutable de ne pas pouvoir distinguer du tout les requêtes DNS: les opérateurs de réseau (privés et d’entreprise) n’ont plus la possibilité de sécuriser leur propre réseau.

En termes de protocole des paquets sur le fil, la seule différence entre les deux approches est que le DoH utilise le même numéro de port TCP que le HTTPS, à savoir le port 443. Avec le DoH, la session DNS ressemble à une simple session HTTPS de plus pour le réseau, mais elle ressemble également à une simple session HTTPS de plus pour la plate-forme hôte. En d’autres termes, un navigateur peut simplement activer DoH. Ce n’est pas l’utilisateur qui l’active, ni la plate-forme, mais le navigateur lui-même. Une des préoccupations est le choix du serveur du DoH. Au lieu d’utiliser un service de résolution de DNS configuré localement et fourni par le FAI, le DoH bascule la situation pour utiliser un service configuré par le navigateur. La mise en place rapide de ce service dans Firefox nécessite la configuration explicite d’un résolveur récursif de confiance, d’une manière similaire à la configuration du serveur DNS over TLS dans Android Pie. Que se passe-t-il si le résolveur DoH est configuré par défaut par le navigateur ?

Le DoH est en mesure de confier le contrôle du paramètre de confidentialité des requêtes DNS au navigateur, en contournant à la fois l’utilisateur et l’infrastructure internet locale. En termes de protection de la vie privée, cela semble très séduisant. L’inconvénient, c’est que le navigateur de l’utilisateur partage toute son activité locale avec le serveur du DoH configuré.

La deuxième grande différence est que le DoT envoie simplement des requêtes DNS via une connexion TLS, tandis que le DoH est essentiellement DNS-over-HTTP-over-TLS, ce qui entraîne une complexité supplémentaire. En mélangeant le DoH avec les protocoles existants, chaque requête et réponse DNS passe par une pile HTTPS. Pour les applications embarquées, c’est un scénario cauchemardesque, mais c’est également incompatible avec presque tous les matériels de sécurité existants.

Le protocole DoT présente un autre avantage : il est déjà mis en œuvre et utilisé depuis bien plus longtemps que le DoH. De nombreux acteurs, dont Cloudflare, Google, certains fournisseurs d’accès internet nationaux et des logiciels de serveur DNS standard comme BIND prennent en charge le protocole DoT dès sa sortie. Sur Android, le DNS over TLS est même utilisé par défaut si le résolveur DNS sélectionné supporte le DoT.

Pourquoi passer à DoH alors que DoT gagne du terrain ? Certaines applications peu respecteuses de la vie privée comme Firefox contournent le DNS basé sur le DoT et utilisent leur propre résolveur DNS, ce qui rend la sécurité très opaque. De même, la résolution du DNS tend aujourd’hui à se déplacer vers des applications individuelles, cela ressemble à un énorme pas en arrière. Savez-vous quel résolveur DNS est utilisé par ces applications ?

Le cryptage n’empêche pas le suivi

Deux grands partisans du DNS over HTTPS sont Cloudflare et Mozilla. Il n’est pas surprenant qu’ils omettent complètement de mentionner le DNSSEC et qu’ils proposent à la place un outil appelé Trusted Recursive Resolver (TRR) ce qui, pour Mozilla, oblige à utilier Cloudflare en tant que résolveur DNS. Vous faîtes entièrement confiance à Cloudflare, vous ? Moi pas.

Partager vos secrets avec Google ressemble un peu à une danse avec le diable. La plateforme publicitaire de Google génère des profils d’utilisateurs complets et ses systèmes de support publicitaire engagent des praticiens experts et compétents dans l’art du capitalisme et de la surveillance ! Pour leur défense, notons que Google déclare clairement qu’il n’utilise pas son service DNS public pour récolter des données sur les profils des utilisateurs et qu’il exerce un contrôle strict sur l’accès aux données du DNS. Mais cela soulève la question de savoir comment de tels engagements sont appliqués au sein de l’entreprise. Google ne s’ouvre à aucune forme de contrôle de conformité par des tiers. Bien que sa déclaration sur la pratique DNS soit une excellente déclaration de noble intention, comment un utilisateur peut-il être assuré que Google respecte dans la pratique chaque détail de cette déclaration ?

Comme l’ont souligné les experts à de nombreuses reprises, le cryptage du DNS n’empêche pas le suivi. Toute demande ultérieure vers une adresse IP qui a été résolue de manière secrète sera toujours visible en clair. Tout le monde saura toujours que vous visitez Facebook.com ou un site web dissident risqué. Aucune quantité de DNS et de cryptage du trafic internet ne peut dissimuler des informations cruciales pour le fonctionnement d’un réseau comme internet.

L’internet du futur

La réponse de Mozilla au problème de suivi d’IP est essentiellement de dire qu’il n’y a pas de problème. Comme de plus en plus de sites web et de réseaux de distribution de contenu (CDN) sont détenus par une poignée de services (Cloudflare, Azure, AWS, etc.), la signification de cette IP unique devient de moins en moins significative. Il suffirait de faire confiance au service Cloud que vous choisissez pour héberger vos données et prier pour qu’il ne vole pas vos données ou qu’il ne tombe pas en panne.

En 2019, une panne massive a eu lieu le 24 juin, lorsqu’une erreur de configuration chez Verizon a entraîné l’indisponibilité de Cloudflare, Amazon, Linode et de nombreux autres services pendant une grande partie de la journée. Le 2 juillet 2019, Cloudflare a été indisponible pendant environ une demi-heure, entraînant dans sa chute de nombreux sites web qui dépendent de ses services.

En conséquence, Office365, hébergé par Microsoft dans le nuage, a également connu une panne de plusieurs heures le même jour, laissant un grand nombre de ses utilisateurs bloqués et incapables d’utiliser le service. Pendant ce temps, durant le week-end de la Fête du travail aux États-Unis, une panne de courant dans le centre de données US-East1 d’AWS a entraîné la disparition d’un To de données clients. Centraliser internet, est-ce réellement une bonne chose ?

L’ancien revient à la mode

Il est étonnant que dans toute cette discussion sur la vie privée et le suivi, il n’y ait aucune mention des réseaux privés virtuels (VPN). Ils permettent pourtant de résoudre les problèmes de cryptage de vos données et de requêtes DNS, de masquage de votre adresse IP et bien plus encore, simplement en déplaçant le point où votre PC et tout autre appareil connecté à internet « existe » sur internet.

Les VPN sont très couramment utilisés par les dissidents des régimes autoritaires pour contourner la censure sur internet et, avec des formes spécialisées comme le réseau Tor, constituent un élément crucial de la liberté en ligne.

Si l’on peut faire confiance à une grande entité commerciale comme Cloudflare, il devrait être tout aussi facile de trouver un fournisseur de VPN digne de confiance qui ne stockera ni ne vendra vos données. D’une manière différente, le navigateur Opera est livré avec un proxy intégré gratuit qui offre quelques avantages.

Conclusion

Il est incroyablement difficile de démontrer que le DoH renforce la protection de la vie privée. Ce n’est probablement pas le cas. Il est plus facile de soutenir que le DoH a le potentiel de changer les parties que vous faites entrer dans votre cercle de confiance en raison de la possibilité d’accéder à votre profil privé, et pas nécessairement de la bonne manière. En soi, une telle substitution de confiance ne devrait pas être une source de préoccupation. Mais avec le DoH, c’est votre navigateur qui décide à qui vous faîtes confiance avec vos données personnelles, pas vous. Les parties qui cherchent à être votre partenaire de confiance sont les mêmes qui ont un intérêt direct à vous vendre à l’annonceur le plus offrant.

En résumé, on peut dire que le DoH fait mal ce que le DoT fait déjà. A la place, il faudrait se concentrer sur la mise en œuvre complète du DNSSEC partout. Et si votre objectif est d’assurer une véritable protection de la vie privée en évitant le suivi, alors vous devriez vous intéresser aux VPN, surtout si vous êtes un dissident piégé dans un régime autoritaire.