La transparence est l’une des caractéristiques déterminantes d’Internet depuis aussi longtemps qu’elle existe, et une grande partie du trafic est aujourd’hui encore passée sans aucune forme de cryptage. La plupart des demandes de pages HTML et de contenu associé sont en texte brut et les réponses sont renvoyées de la même manière, même si HTTPS existe depuis 1994.
Mais parfois, il y a un besoin de sécurité et / ou de confidentialité. Bien que le cryptage du trafic Internet soit devenu plus répandu pour les transactions bancaires en ligne, les achats, l’aspect protection de la confidentialité de nombreux protocoles Internet n’a pas suivi le même rythme. En particulier, lorsque vous recherchez l'adresse IP d'un site Web par nom d'hôte, la demande DNS est presque toujours transmise en texte brut, ce qui permet à tous les ordinateurs et aux fournisseurs de services Internet de déterminer le site Web sur lequel vous êtes en train de naviguer, même si vous utilisez HTTPS une fois la connexion établie. est fait.
L’idée de chiffrer également les requêtes DNS n’est pas tout à fait nouvelle, les premières tentatives ayant débuté au début des années 2000, sous la forme DNSCrypt, DNS sur TLS (DoT), etc. Mozilla, Google et quelques autres grandes sociétés Internet proposent une nouvelle méthode de chiffrement des requêtes DNS: DNS over HTTPS (DoH).
DoH non seulement chiffre la requête DNS, mais la transmet également à un serveur Web «normal» plutôt qu’à un serveur DNS, ce qui rend le trafic de requêtes DNS pratiquement impossible à distinguer de HTTPS normal. C'est une épée à double tranchant. Comme DNSCrypt ou DoT protège la requête DNS elle-même, il empêche également les responsables de la sécurité dans les grandes entreprises de surveiller les usurpations DNS et transfère la responsabilité d'une fonction réseau critique du système d'exploitation vers un système d'exploitation. application. En outre, cela ne fait rien de cacher l’adresse IP du site Web que vous venez de regarder – vous allez quand même le visiter, après tout.
De plus, par rapport à DoT, DoH centralise les informations relatives à votre navigation dans quelques entreprises: pour le moment, Cloudflare, qui dit jeter ses données dans les 24 heures, et Google, qui semble vouloir conserver et monétiser chaque détail de tout ce qui vous concerne. J'ai jamais pensé à faire.
Le DNS et la confidentialité sont des sujets importants, nous allons donc entrer dans les détails ici.
Sommaire
Serveurs de noms et confiance
Le concept du système de noms de domaine remonte à ses jours ARPANET, lorsqu'un fichier texte unique sur chaque nœud ARPANET – appelé HOSTS.TXT – contenait le mappage des noms de système sur ARPANET avec leurs adresses numériques. Lorsque vous avez écrit ce fichier vous-même, il était facile de s’assurer de son exactitude. Au fur et à mesure que le réseau grandissait, il devenait irréaliste de conserver les copies centrale et locale de ce fichier. Au début des années 80, des efforts étaient en cours 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’UC Berkeley, basé sur les RFC 882 et RFC 883. En 1987, la norme DNS avait été révisée à plusieurs reprises. RFC 1034 et RFC 1035, qui sont restés en grande partie inchangés depuis lors.
La structure essentielle du DNS est celle d'une configuration arborescente, avec ses nœuds et ses feuilles subdivisées en zones. La zone racine DNS est la zone de niveau supérieur, composée de treize clusters de serveurs racine, qui forment les serveurs racine DNS faisant autorité. Tout serveur DNS nouvellement configuré (par exemple, chez un fournisseur de services Internet ou dans une entreprise) finira par obtenir ses enregistrements DNS auprès d’au moins un de ces serveurs.
Chaque zone DNS supplémentaire ajoute un autre domaine au système de noms. Chaque pays a tendance à gérer ses propres domaines, avec des domaines spéciaux (tels que .org, .com) qui ne sont pas liés à un pays spécifique géré par une entité distincte. Lors de la résolution d’un nom de domaine à l’aide de DNS, il s’agit de commencer par le nom de domaine (par exemple, .com), puis le nom (par exemple, «google») et enfin tous les sous-domaines. Cela peut impliquer quelques déplacements à travers les zones DNS si les données demandées n'ont pas déjà été mises en cache.
DNSSEC: Ajout de la confiance au DNS
Avant de commencer à chiffrer les demandes DNS, il est important de s’assurer que le serveur DNS auquel nous parlons est digne de confiance. La nécessité de cela est apparue clairement dans les années 90 et a débouché sur la première norme utilisable DNS Security Extensions (DNSSEC) (RFC 2353) et le RFC 4033 révisé (DNSSEC-bis).
DNSSEC fonctionne en signant les enregistrements de recherche DNS avec une cryptographie à clé publique. L'authenticité d'un enregistrement DNS peut ainsi être vérifiée par les clés publiques de la zone racine DNS, qui est le tiers de confiance dans ce scénario. Les propriétaires de domaine génèrent leurs propres clés, qui sont signées par l'opérateur de zone et ajoutées au DNS.
Si DNSSEC permet d’être relativement certain que les réponses fournies par le résolveur DNS est authentique, cela nécessite que DNSSEC soit activé dans son système d’exploitation. Malheureusement, peu de systèmes d’exploitation implémentent un service DNS qui ne se limite pas à la «compatibilité DNSSEC», c’est-à-dire qu’ils ne valident pas les réponses DNS. Cela signifie qu'aujourd'hui, on ne peut pas être sûr que les réponses DNS que l'on reçoit sont authentiques.
Les problèmes avec DoH
Mais imaginons que vous utilisez DNSSEC. Vous êtes maintenant prêt à chiffrer la communication pour ajouter un niveau de confidentialité à la transaction. Il existe un certain nombre de motivations pour garder secrètes les requêtes DNS de nos yeux. Les raisons les plus innocentes sont notamment d’éviter les filtres des entreprises et des fournisseurs de services Internet, d’empêcher le suivi des habitudes Internet, etc. Éviter la persécution politique pour avoir exprimé son point de vue sur Internet est un motif plus grave. Naturellement, le cryptage des requêtes DNS empêche les utilisateurs d’observer ces requêtes, mais cela ignore les problèmes de sécurité les plus importants liés au DNS et, bien entendu, à tous les autres protocoles de communication.
Ici, les principaux candidats sont DoT, utilisant TLS, et le DoH proposé, utilisant HTTPS. La différence la plus évidente entre les deux est le port sur lequel ils sont exécutés: le DoT a un port dédié, TCP 853, tandis que DoH se mélange au reste du trafic HTTPS sur le port 443. Cela présente l’avantage discutable de ne pas pouvoir distinguer les requêtes DNS, ce qui signifie qu'il supprime les options offertes aux opérateurs de réseaux (privés et entreprises) pour sécuriser leur propre réseau, en tant que l'un des architectes derrière DNS, Paul Vixie, a souligné sur Twitter l'année dernière.
La deuxième différence principale est que, tandis que DoT envoie simplement des requêtes DNS via une connexion TLS, DoH est essentiellement DNS-over-HTTP-over-TLS, produisant ainsi son propre type de média mime. application / message-dns et une complexité ajoutée significative. En mélangeant DoH avec des protocoles existants, cela signifie que chaque demande et chaque réponse DNS passe par une pile HTTPS. Pour les applications intégrées, il s'agit d'un scénario cauchemardesque, mais il est également incompatible avec presque tous les éléments de matériel de sécurité existants.
DoT a l’avantage supplémentaire d’être déjà implémenté et d’être utilisé depuis bien plus longtemps que DoH, avec de nombreuses parties, y compris Cloudflare, Google, certains FAI nationaux et un logiciel de serveur DNS standard tel que BIND prenant en charge DoT immédiatement. Sur Android Pie (version 9, pour ceux qui gardent la trace) et les versions ultérieures, DNS sur TLS sera utilisé par défaut si le résolveur DNS sélectionné prend en charge DoT.
Pourquoi passer à DoH alors que DoT gagne enfin du terrain? Les applications malveillantes telles que Firefox contournent le DNS basé sur DoT du système et utilisent son propre résolveur DNS sur DoH à la place, ce qui crée une situation de sécurité extrêmement opaque. Comme nous le voyons maintenant, la résolution du DNS passerait à des applications individuelles, ce qui semble être un grand pas en arrière. Savez-vous quel résolveur DNS utilise chaque application? Si cela se mélange au trafic du port TCP 443, comment le sauriez-vous?
Le cryptage n'arrête pas le suivi
Cloudflare et Mozilla sont les deux grands partis derrière DNS via HTTPS, ce dernier ayant produit ce petit dessin animé dans lequel ils tentent d’expliquer DoH. Sans surprise, dans ce document, ils omettent complètement de mentionner DNSSEC (bien que référencé comme "crucial" dans la RFC 8484), proposant à la place quelque chose appelé "Trusted Recursive Resolver (TRR)", qui semble fondamentalement signifier "utiliser un résolveur DNS de confiance", qui pour Mozilla signifie 'Cloudflare'.
Sans aucun lien avec DoH, ils mentionnent une norme appelée "minimisation de QNAME" (RFC 7816) qui vise à réduire la quantité d’informations non critiques que le résolveur DNS envoie au DNS, comme indiqué dans cet article du blog Verisign. Comme dit, cette norme n'a aucune incidence sur DoH et fonctionnerait même bien sans cryptage DNS. Comme DNSSEC, il s’agit d’une nouvelle évolution de la norme DNS qui améliore ses aspects de sécurité et de confidentialité.
Le kicker se trouve cependant dans la section «Ce qui n’est pas corrigé par TRR avec DoH? Comme l'ont souligné à maintes reprises les experts, le cryptage DNS n'empêche pas le suivi. Toute demande ultérieure adressée à l'adresse IP résolue si secrètement restera visible en clair. Tout le monde saura quand même que vous visitez Facebook.com ou ce site dissident risqué. Aucune quantité de cryptage DNS et de trafic Internet ne dissimulera des informations cruciales au fonctionnement d'un réseau comme Internet.
L'avenir d'Internet est-il un point d'échec unique?
La réponse de Mozilla au problème de suivi IP consiste essentiellement à dire qu’il n’ya pas de problème, à cause du Cloud. Alors que de plus en plus de sites Web et de réseaux de distribution de contenu (CDN) sont regroupés dans une poignée de services (Cloudflare, Azure, AWS, etc.), la signification de cette adresse IP devient de moins en moins significative, vous devez faire confiance à n'importe quel service Cloud. vous choisissez de ne pas voler vos données, ou de descendre pendant une journée.
Cette année, il y a eu un événement d'indisponibilité massif le 24 juin, lorsqu'une erreur de configuration chez Verizon a provoqué l'indisponibilité de Cloudflare, Amazon, Linode et de nombreuses autres personnes pendant une grande partie de la journée. Puis, le 2 juillet de cette année, Cloudflare dans son ensemble s’est éteint pendant environ une demi-heure, emportant avec lui de nombreux sites Web qui reposent sur ses services.
Par coïncidence, Office365 hébergé sur le cloud de Microsoft a également subi une panne de plusieurs heures le même jour, laissant nombre de ses utilisateurs bloqués et incapables d’utiliser le service. Pendant le week-end de la fête du travail des États-Unis, une panne de courant sur le centre de données AWS US-East-1 a entraîné la disparition de 1 To de données clients, le matériel sur lequel il était stocké étant devenu FUBAR. Il est clair que certains problèmes doivent être résolus avec ce message «Centraliser Internet est bon».
Ce qui est vieux est nouveau
À bien des égards, il est renversant de constater que dans toute cette discussion sur la confidentialité et le suivi, il n’est fait aucune mention des réseaux privés virtuels (VPN). Celles-ci résolvent le problème du cryptage de vos données et de vos requêtes DNS, du masquage de votre adresse IP, et bien plus encore, simplement en déplaçant le point où votre PC ou autre périphérique compatible Internet existe (également) sur Internet. Les VPN sont très couramment utilisés par les dissidents des régimes autoritaires depuis des décennies pour contourner la censure sur Internet et, avec des formes spécialisées telles que le réseau Tor, ils constituent un élément crucial de la liberté en ligne.
Si vous pouvez faire confiance à une grande entité commerciale telle que Cloudflare dans un système comme DoH, trouver un fournisseur de réseau privé virtuel digne de confiance, qui ne stockera ni ne vendra vos données, sera tout aussi facile. Mieux encore, le navigateur Opera est fourni avec un proxy intégré gratuit qui offre de nombreux avantages du VPN.
En résumé, on peut affirmer que DoH honore son acronyme en faisant mal ce que DoT fait déjà. L'accent devrait être mis davantage sur la mise en œuvre complète de DNSSEC partout avec la minimisation de DoT et QNAME. Et si votre objectif est de préserver votre vie privée en esquivant le suivi, alors vous devriez vous pencher sur les VPN, en particulier si vous êtes un dissident pris au piège d’un régime autoritaire.
Commentaires
Laisser un commentaire