Les ingénieurs de Cloudflare, Apple et du réseau de distribution Fastly ont mis au point Oblivious DoH, un changement majeur du système de noms de domaine actuel qui traduit des noms de domaine conviviaux en adresses IP dont les ordinateurs ont besoin pour trouver d'autres ordinateurs sur Internet. Les entreprises travaillent avec l'Internet Engineering Task Force (IETF, organisme qui élabore et promeut des standards Internet, en particulier les standards qui composent la suite de protocoles Internet) dans l'espoir qu'il deviendra une norme à l'échelle de l'industrie. Abrégé en ODoH, Oblivious DoH s'appuie sur une amélioration DNS distincte appelée DNS-over-HTTPS (abrégé DoH), qui n'en est qu'à ses tout débuts d'adoption.Tout d'abord, il est important de mettre les éléments dans leurs contextes. DNS est une base de données qui relie un nom convivial, tel que www.developpez.com, à une série de nombres informatisés, appelée une adresse IP (par exemple 192.0.2.1). En effectuant une « recherche » dans cette base de données, votre navigateur Web peut trouver des sites Web en votre nom. En raison de la conception initiale du DNS il y a des décennies, les navigateurs effectuant des recherches DNS pour les sites Web (même les sites https:// chiffrés) devaient effectuer ces recherches sans chiffrement. Parce qu'il n'y a pas de chiffrement, d'autres appareils en cours de route peuvent également collecter (ou même bloquer ou modifier) ces données. Les recherches DNS sont envoyées à des serveurs qui peuvent espionner l'historique de navigation de votre site Web sans vous en informer ou publier une politique sur ce qu'ils font de ces informations.
Lors de la création d’Internet, ce type de menaces à la vie privée et à la sécurité des personnes était connu, mais n’était pas encore exploité. Aujourd'hui, nous savons que le DNS non chiffré est non seulement vulnérable à l'espionnage, mais également exploité, et les acteurs de l'industrie ont apporté leur aide afin qu'Internet puisse opter pour des alternatives plus sécurisées. Pour ce faire, des navigateurs ont choisi d’effectuer des recherches DNS dans une connexion HTTPS chiffrée. Cela permet de masquer votre historique de navigation aux attaquants sur le réseau, d'empêcher la collecte de données par des tiers sur le réseau qui relie votre ordinateur aux sites Web que vous visitez.
C’est ainsi que le protocole DNS-over-HTTPS a vu le jour ; il donne la possibilité aux navigateurs Web de masquer les requêtes et les réponses DNS dans le trafic HTTPS d’apparence normale afin de rendre le trafic DNS d’un utilisateur invisible. Il compromet par la même occasion la capacité des observateurs tiers du réseau (tels que les FAI) à détecter et filtrer le trafic de leurs clients.
Pour protéger le DNS des entités tierces, l’IETF a normalisé le chiffrement DNS avec DNS over HTTPS (DoH) et DNS over TLS (DoT). Les deux protocoles empêchent les requêtes d'être interceptées, redirigées ou modifiées entre le client et le résolveur. La prise en charge des clients pour DoT et DoH se développe, ayant été implémentée dans les versions récentes de Firefox, iOS, et plus encore. En théorie, la mise en œuvre à grande échelle de cette technologie permettrait aussi de lutter plus efficacement contre l’Eavesdropping et la manipulation de DNS par des attaques de l’homme du milieu.
Les fournisseurs à offrir un service public DoH / DoT ne sont pas légion (notons que Cloudflare en fait partie). Aussi, jusqu'à ce qu'il y ait un déploiement plus large parmi les fournisseurs de services Internet, il y a deux préoccupations principales qui sont soulevées :
- L’une d’elles est que la centralisation du DNS introduit des points de défaillance uniques.
- L'autre problème est que le résolveur peut toujours lier toutes les requêtes aux adresses IP des clients.
Comment fonctionne Oblivious DNS over HTTPS (ODoH)?
ODoH est un protocole émergent en cours de développement à l'IETF. ODoH fonctionne en ajoutant une couche de chiffrement à clé publique, ainsi qu'un proxy réseau entre les clients et les serveurs DoH tels que 1.1.1.1. Selon Cloudflare, la combinaison de ces deux éléments ajoutés garantit que seul l'utilisateur a accès à la fois aux messages DNS et à sa propre adresse IP en même temps.
Il y a trois acteurs sur la voie ODoH. En regardant la figure ci-dessus, commençons par la cible. La cible déchiffre les requêtes chiffrées par le client, via un proxy. De même, la cible chiffre les réponses et les renvoie au proxy. La norme dit que la cible peut être ou non le résolveur (nous y reviendrons plus tard). Le proxy fait ce qu'un proxy est censé faire, en ce sens qu'il transfère les messages entre le client et la cible. Le client se comporte comme il le fait dans DNS et DoH, mais diffère en chiffrant les requêtes pour la cible et en déchiffrant les réponses de la cible. Tout client qui choisit de le faire peut spécifier un proxy et une cible de son choix.
Ensemble, le chiffrement et le proxy ajoutés offrent les garanties suivantes :
- La cible ne voit que la requête et l'adresse IP du proxy.
- Le proxy n'a aucune visibilité sur les messages DNS, il n'a pas la possibilité d'identifier, de lire ou de modifier la requête envoyée par le client ou la réponse renvoyée par la cible.
- Seule la cible prévue peut lire le contenu de la requête et produire une réponse.
Ces trois garanties améliorent la confidentialité des clients tout en maintenant la sécurité et l'intégrité des requêtes DNS. Cependant, chacune de ces garanties repose sur une propriété fondamentale (que le proxy et les serveurs cibles ne soient pas en commun). Tant qu'il n'y a pas de collusion, un attaquant ne peut réussir que si le proxy et la cible sont compromis.
Cloudflare explique :
« Un aspect de ce système qui mérite d'être souligné est que la cible est distincte du résolveur récursif en amont qui effectue la résolution DNS. En pratique, pour la performance, nous nous attendons à ce que l'objectif soit le même. En fait, 1.1.1.1 est désormais à la fois un résolveur récursif et une cible! Il n'y a aucune raison pour laquelle une cible doit exister séparément de tout résolveur. S'ils sont séparés, la cible est libre de choisir des résolveurs et d'agir simplement comme un intermédiaire. La seule vraie exigence, rappelez-vous, est que le proxy et la cible ne s'entendent jamais.
« De plus, il est important de noter que les clients contrôlent totalement la sélection des proxys et des cibles. Sans aucun besoin de programmes de type TRR, les clients peuvent bénéficier de la confidentialité de leurs requêtes, en plus de la sécurité. Étant donné que la cible ne connaît que le proxy, la cible et tout résolveur en amont ignorent l'existence des adresses IP des clients. Plus important encore, cela permet aux clients de mieux contrôler leurs requêtes et la manière dont elles peuvent être utilisées. Par exemple, les clients peuvent sélectionner et modifier leurs proxys et leurs cibles à tout moment, pour n'importe quelle raison ! »
Flux de messages ODoH
Dans ODoH, le «O» signifie oblivious (littéralement inconscient), et cette propriété provient du niveau de chiffrement des messages DNS eux-mêmes. Ce chiffrement ajouté est « de bout en bout » entre le client et la cible, et indépendant du chiffrement au niveau de la connexion fournie par TLS / HTTPS. On pourrait se demander pourquoi ce chiffrement supplémentaire est nécessaire en présence d'un proxy. En effet, deux connexions TLS distinctes sont nécessaires pour prendre en charge la fonctionnalité de proxy. Plus précisément, le proxy met fin à une connexion TLS du client et initie une autre connexion TLS à la cible. Entre ces deux connexions, les contextes de message DNS apparaîtraient autrement en texte brut ! Pour cette raison, ODoH chiffre également les messages entre le client et la cible afin que le proxy n'ait pas accès au contenu du message.
L'ensemble du processus commence par les clients qui chiffrent leur requête pour la cible à l'aide de HPKE. Les clients obtiennent la clé publique de la cible via DNS, où elle est regroupée dans un enregistrement de ressource HTTPS et protégée par DNSSEC. Lorsque la durée de vie de cette clé expire, les clients demandent une nouvelle copie de la clé si nécessaire (comme ils le feraient pour un enregistrement A / AAAA lorsque la durée de vie de cet enregistrement expire). L’utilisation de la clé publique validée par DNSSEC d’une cible garantit que seule la cible prévue peut déchiffrer la requête et chiffrer une réponse.
Les clients transmettent ces requêtes chiffrées à un proxy via une connexion HTTPS. Dès réception, le proxy transmet la requête à la cible désignée. La cible déchiffre ensuite la requête, produit une réponse en envoyant la requête à un résolveur récursif tel que 1.1.1.1, puis chiffre la réponse au client. La requête chiffrée du client contient du matériel de clé encapsulé à partir duquel les cibles dérivent la clé symétrique de chiffrement de réponse.
Cette réponse est ensuite renvoyée au proxy, puis transmise au client. Toutes les communications sont authentifiées et confidentielles puisque ces messages DNS sont chiffrés de bout en bout, bien qu'ils soient transmis sur deux connexions HTTPS distinctes (client-proxy et proxy-cible). Le message qui apparaît autrement au proxy sous forme de texte brut est en fait un brouillage chiffré.
Un travail en cours
Le message indique que les ingénieurs mesurent toujours le coût des performances de l'ajout du proxy et du chiffrement. Les premiers résultats semblent toutefois prometteurs. Dans une étude, la surcharge supplémentaire entre une requête / réponse DoH proxy et son homologue ODoH était inférieure à 1 milliseconde au 99e centile. Cloudflare fournit une discussion beaucoup plus détaillée des performances ODoH dans son billet.
Jusqu'à présent, ODoH reste un travail en cours. Avec le soutien de Cloudflare, les contributions d'Apple et de Fastly (ainsi que l'intérêt affiché d'acteurs comme Firefox et d'autres), ODoH mérite d'être pris au sérieux. Dans le même temps, l'absence de Google, Microsoft et d'autres acteurs clés suggère qu'il reste encore un long chemin à parcourir.
Ce qui est clair, c'est que le DNS reste extrêmement faible. Les critiques des alternatives apportées par DoH et DoT ont évoqué entre autres leur crainte que la confidentialité soit échangée contre la sécurité. Si ODoH peut convertir ces critiques et ne brise pas Internet durant le processus, nous en entendrons encore certainement parler et d'autres grands noms de l'industrie pourraient rejoindre l'aventure.
Source : Cloudflare
Et vous ?
Que pensez-vous de cette approche ?