HTTPS DNS - Solution à moitié et incorrecte

Tout au long de l'existence d'Internet, l'ouverture a été l'une de ses caractéristiques déterminantes, et la plupart du trafic actuel est toujours transmis sans aucun cryptage. La plupart des demandes de pages HTML et de contenu connexe sont effectuées en texte brut et les réponses sont renvoyées de la même manière, malgré le fait que le protocole HTTPS existe depuis 1994.

Cependant, il existe parfois un besoin de sécurité et / ou de confidentialité. Bien que le cryptage du trafic Internet soit répandu dans des domaines tels que les services bancaires en ligne et les achats, le problème du maintien de la confidentialité dans de nombreux protocoles Internet n'a pas été résolu aussi rapidement. En particulier, lorsque vous interrogez l'adresse IP d'un site pour un hôte, une requête DNS est presque toujours transmise en texte clair, ce qui permet à tous les ordinateurs et fournisseurs de déterminer le site que vous visitez, même si vous utilisez HTTPS après avoir établi une connexion.

L'idée que le chiffrement est également nécessaire pour les requêtes DNS n'est pas nouvelle, et les premières tentatives ont été faites dans les années 2000 - DNSCrypt, DNS sur TLS (DoT), etc. Mozilla, Google et d'autres grandes sociétés Internet font la promotion d'une nouvelle méthode de chiffrement des requêtes DNS : DNS sur HTTPS (DoH).

Le DoH non seulement crypte la requête DNS, mais la transfère également au serveur Web «normal», et non au serveur DNS, ce qui rend le trafic DNS impossible à distinguer du HTTPS normal. Cette pièce a deux faces. Cette procédure protège la requête DNS elle-même, comme DNSCrypt ou DoT, et empêche également les gars des services de sécurité des grandes entreprises de suivre l'usurpation DNS et transfère la responsabilité des fonctions réseau critiques du système d'exploitation à l'application. Et cela n'aide en rien à cacher l'adresse IP du site Web que vous venez de demander - après tout, vous y allez quand même.

Par rapport à DoT, DoH centralise les informations sur les sites que vous avez visités dans plusieurs entreprises: aujourd'hui c'est Cloudflare, qui promet de se débarrasser de vos données en 24 heures, et Google, qui entend sauvegarder et monétiser tous les détails de tout ce que vous avez prévu de faire.

Le DNS et la confidentialité sont des sujets importants, alors approfondissons les détails.

Serveur DNS et confiance

Le concept d'un système de noms de domaine remonte à ARPANET , lorsque le seul fichier texte sur chaque nœud ARPANET - sous le nom HOSTS.TXT - contenait toute la correspondance entre les noms des systèmes connectés à ARPANET et leurs adresses numériques. Lorsque vous avez reconstitué ce fichier vous-même, il était facile de vérifier qu'il était correct. Avec la croissance du réseau, il est devenu irréaliste de conserver des copies centrales et locales de ces fichiers. Au début des années 80, des tentatives avaient déjà commencé pour créer un système d'automatisation pour ce processus.

Le premier serveur de noms (Berkeley Internet Name Domain Server ou BIND) a été écrit en 1984 par un groupe d'étudiants de l'Université de Californie à Berkeley, sur la base des RFC 882 et RFC 883. En 1987, la norme DNS a été révisée plusieurs fois, conduisant à l'avènement des RFC 1034 et RFC 1035 qui depuis lors, dans l'ensemble, n'ont pas changé.



La base de la structure DNS est sa structure arborescente, où les nœuds et les feuilles sont divisés en zones. La zone racine DNS est le niveau supérieur, composé de treize groupes de serveurs racine qui forment les serveurs DNS racine officiels. Tout nouveau serveur DNS (créé par un fournisseur ou une entreprise) reçoit des enregistrements DNS d'au moins un de ces serveurs principaux.

Chaque zone DNS suivante ajoute un autre domaine au système de noms. En règle générale, chaque pays gère ses propres domaines et les domaines .org ou .com qui ne sont pas associés à des pays sont desservis séparément. Une requête pour un nom d'hôte via DNS commence par un nom de domaine (par exemple, .com), puis par un nom (par exemple, google), suivi de sous-domaines possibles. Si les données n'ont pas encore été mises en cache, vous devrez peut-être effectuer plusieurs transitions via les zones DNS pour résoudre la demande.

DNSSEC: ajouter de la confiance au système DNS

Avant de procéder au chiffrement des requêtes DNS, vous devez vous assurer que nous pouvons faire confiance au serveur DNS. Ce besoin est devenu apparent dans les années 1990 et a conduit aux premières extensions opérationnelles de la norme de sécurité DNS (DNSSEC), de la RFC 2353 et de la RFC 4033 révisée (DNSSEC-bis).


Carte Internet 2006

DNSSEC fonctionne en signant les enregistrements de requête DNS avec une clé publique. L'authenticité de l'enregistrement DNS peut être confirmée par les clés publiques de la zone racine DNS, qui est un tiers de confiance dans ce scénario. Les propriétaires de domaine génèrent leurs clés, signées par les opérateurs de zone et ajoutées au DNS.

Bien que DNSSEC vous permette d'être relativement sûr que les réponses du serveur DNS sont réelles, ce protocole doit être inclus dans le système d'exploitation. Malheureusement, peu de systèmes d'exploitation mettent en œuvre un service DNS qui peut faire plus que simplement «connaître DNSSEC», c'est-à-dire qu'ils ne confirment pas réellement les réponses DNS. Donc, aujourd'hui, vous ne pouvez pas être sûr que les réponses que vous recevez du DNS sont réelles.

Problème avec DoH

Supposons que vous utilisez DNSSEC. Vous êtes prêt à crypter les messages pour ajouter de la confidentialité à votre transfert de données. Il peut y avoir de nombreuses raisons de garder les requêtes DNS secrètes des regards indiscrets. Parmi les plus innocents, il faut contourner les filtres de l'entreprise et des fournisseurs, interdire la surveillance des habitudes Internet, et plus encore. Parmi les plus graves, il y a les tentatives d'éviter la persécution par le gouvernement pour avoir exprimé des opinions politiques sur Internet. Naturellement, le chiffrement des requêtes DNS ne permet pas aux utilisateurs d'espionner ces requêtes, mais en conséquence, des problèmes plus importants avec la sécurité du DNS et, bien sûr, tous les autres protocoles de communication sont ignorés.

Les principaux concurrents ici sont DoT utilisant TLS et DoH utilisant HTTPS. La différence la plus évidente entre les deux est le port: DoT s'exécute sur un port TCP dédié 853, et DoH se mélange avec d'autres trafics HTTPS sur le port 443. Cela donne l'avantage controversé de rendre les requêtes DNS indiscernables des autres trafics, ce qui rend impossible pour les opérateurs de réseau (privés et entreprises) ) sécurisez votre propre réseau, comme l'a annoncé l'année dernière Paul Vixie, l'un des architectes DNS.

La deuxième des principales différences est que si DoT envoie simplement des requêtes DNS sur TLS, alors DoH est essentiellement DNS sur HTTP-sur TLS, nécessite sa propre application Type de média / message DNS et rend les choses beaucoup plus compliquées. Le mélange de DoH avec les protocoles existants fait que chaque requête et réponse DNS passe par la pile HTTPS. C'est un cauchemar pour les applications embarquées et est également incompatible avec presque tous les types d'équipements existants.

DoT a un autre avantage - ce protocole a déjà été mis en œuvre, et bien plus longtemps que DoH existe, il est utilisé par des sociétés telles que Cloudflare, Google, ainsi que des fournisseurs Internet locaux; Le logiciel serveur standard comme BIND utilise DoT dès la sortie de la boîte. Sur Android Pie OS (version 9), DNS sur TLS sera utilisé par défaut si le serveur DNS sélectionné prend en charge DoT.

Pourquoi passer au DoH si DoT est déjà en cours de déploiement? Si des applications non standard telles que Firefox contournent le système DNS basé sur DoT et utilisent leur propre système de récupération de nom de domaine via DoH, cette situation deviendra très difficile d'un point de vue de sécurité. Le transfert de DNS vers des applications individuelles, qui se produit actuellement, semble être un pas en arrière. Connaissez-vous la méthode DNS utilisée par chaque application? Savez-vous qu'il mélange ce processus avec le trafic TCP sur le port 443?

Le chiffrement n'interfère pas avec l'espionnage

Deux grandes entreprises, Cloudflare et Mozilla, représentent DNS sur HTTPS, et ce dernier a même publié une jolie petite bande dessinée , où il essaie d'expliquer le schéma DoH. Sans surprise, ils ne mentionnent pas du tout DNSSEC (même s'il est appelé «critique» dans la RFC 8484), et proposent plutôt quelque chose appelé Trusted Recursive Resolver (TRR), qui représente essentiellement les conseils «utiliser de confiance Serveur DNS »par lequel Mozilla signifie Cloudflare.

En plus de DoH, ils mentionnent la norme de minimisation QNAME ( RFC 7816 ), qui devrait réduire la quantité d'informations non critiques envoyées par le serveur DNS. Dans le même temps, cette norme ne dépend en aucune façon du DoH et fonctionnera sans aucun cryptage DNS. Comme avec DNSSEC, la sécurité et la confidentialité sont améliorées grâce à l'évolution de la norme DNS.

Le plus intéressant est contenu dans la section «Qu'est-ce que TRR + DoH ne corrige pas»? Comme l'ont dit de nombreux experts, le chiffrement DNS n'empêche pas l'espionnage. Toute demande ultérieure à l'adresse IP qui a été reçue d'une manière terriblement secrète sera toujours clairement visible. Ils sauront tout de même que vous avez visité Facebook.com ou le site des dissidents. Aucun cryptage du DNS ou du trafic Internet ne masquera des informations vitales pour le fonctionnement d'un réseau tel qu'Internet.

Le futur Internet deviendra-t-il un point de défaillance unique?

Mozilla propose de traiter le problème de l'espionnage IP simplement en déclarant que ce n'est pas un problème grâce à l'utilisation du Cloud. Plus de sites Web et de réseaux de distribution de contenu (CDN) s'accrochent à un petit nombre de services (Cloudflare, Azure, AWS, etc.), moins cette adresse IP unique signifie - il vous suffit de croire que celle choisie votre service cloud ne volera pas vos données et ne tombera pas pendant une journée.

Cette année, le 24 juin, il y a eu une baisse massive des services, lorsqu'une erreur de configuration faite par le fournisseur Verizon a rendu Cloudflare, Amazon, Linode et bien d'autres indisponibles pendant la majeure partie de la journée. Le 2 juillet de cette année , Cloudflare est tombé pendant environ une demi-heure, et avec lui de nombreux sites Web qui dépendent de ses services.

Par coïncidence, le service cloud Office365 de Microsoft a également duré plusieurs heures ce jour-là, c'est pourquoi de nombreux utilisateurs n'ont pas pu utiliser ses services. Le week-end avant la fête du Travail [Fête nationale américaine célébrée le premier lundi de septembre / env. trans.] une panne de courant dans le centre de données AWS US-East-1 a conduit à un téraoctet de données client stockées dans celui-ci recouvert d'un bassin en cuivre . De toute évidence, il existe encore certains inconvénients à l'idée des avantages de la centralisation d'Internet.

De vieilles chansons d'une manière nouvelle

Étonnamment, il n'y a aucune mention de réseaux privés virtuels (VPN) dans cette discussion sur la confidentialité et le suivi. Ils résolvent les problèmes de cryptage des données et des requêtes DNS, en masquant l'adresse IP et plus encore, simplement en déplaçant le point auquel votre PC ou autre appareil connecté à Internet se connecte à Internet. Les dissidents au sein des régimes autoritaires utilisent les VPN depuis des décennies pour contourner la censure sur Internet; Les VPN, y compris des fonctionnalités spéciales comme Tor, sont un élément essentiel de la liberté d'Internet.


Comment fonctionne Tor

Si vous faites confiance à une grande entreprise commerciale comme Cloudflare dans un système comme DoH, il sera facile de trouver un fournisseur VPN de confiance qui ne stocke ni ne vend vos données. Et le navigateur Opera a généralement un support proxy gratuit et intégré, qui offre de nombreux avantages VPN .

Au final, on peut dire que le DoH confirme son acronyme, faisant mal que le DoT se porte déjà bien [«Doh!» - une exclamation indiquant la stupidité d'une action parfaite, surtout la sienne / env. trad.]. Nous devons nous concentrer davantage sur l'implémentation omniprésente de DNSSEC, avec DoT et la minimisation de QNAME. Et si vous vous souciez d'une réelle confidentialité, vous devez vous tourner vers un VPN.