Nous annonçons aujourd'hui la prise en charge d'une nouvelle proposition de norme DNS (cosignée par les ingénieurs de Cloudflare, Apple et Fastly) séparant les adresses IP des requêtes, de sorte qu'aucune entité ne puisse voir les deux en même temps. Mieux encore, nous avons publié le code source, afin que chacun puisse essayer le protocole ODoH ou exécuter son propre service ODoH !
Le Domain Name System (DNS) constitue la pierre angulaire d'un Internet utilisable par l'humain. Il relie les noms de domaine utilisables, comme cloudflare.com, aux adresses IP et autres informations nécessaires pour se connecter à ce domaine. Vous trouverez un bref aperçu de l'importance du DNS et des problèmes qu'il entraîne dans une précédente publication de blog. Concernant la publication qui nous occupe aujourd'hui, il vous suffit de savoir que, conformément au concept initial et à l'usage encore dominant du DNS, les requêtes sont envoyées en clair. Ceci signifie que toute personne présente sur le chemin réseau entre votre appareil et le résolveur DNS peut voir à la fois la requête contenant le nom de l'hôte (ou du site web) que vous souhaitez atteindre et l'adresse IP qui identifie votre appareil.
Pour protéger le DNS des observateurs et des tiers, l'IETF a normalisé le chiffrement du DNS sous la forme des protocoles DNS over HTTPS (DoH) et DNS over TLS (DoT). Ces deux protocoles permettent d'éviter l'interception, la redirection ou la modification des requêtes entre le client et le résolveur. La prise en charge client des protocoles DoT et DoH se développe depuis leur intégration aux versions récentes de Firefox et iOS, parmi d'autres navigateurs. Malgré cela, et en attendant un déploiement plus vaste parmi les fournisseurs d'accès Internet, Cloudflare constitue l'un des rares prestataires à offrir un service DoH/DoT public. Ceci soulève deux préoccupations principales. La première est que la centralisation du DNS introduit des points de défaillance uniques (toutefois, avec des datacenters situés dans plus de 100 pays, le Cloudflare est conçu pour être toujours accessible). L'autre s'attache au fait que le résolveur est toujours capable de relier l'ensemble des requêtes aux adresses IP des clients.
Cloudflare s'engage à respecter la confidentialité des utilisateurs finaux. Les utilisateurs de notre service public de résolution DNS sont protégés par une politique de confidentialité robuste et contrôlée. Toutefois, pour certains clients, le fait de confier des informations de requête sensibles à Cloudflare constitue un obstacle à l'adoption, même avec une politique de confidentialité aussi stricte. Que se passerait-il si nous pouvions offrir aux utilisateurs la possibilité de supprimer ce problème en lui proposant des garanties techniques, plutôt que de nous reposer sur des politiques de protection de la vie privée et des audits ?
Cloudflare et ses partenaires annoncent aujourd'hui le lancement de la prise en charge d'un outil qui remplit exactement cette fonction : le protocole Oblivious DNS over HTTPS ou ODoH, en abrégé.
Partenaires ODoH
Nous sommes heureux d'annoncer le lancement du protocole ODoH avec plusieurs partenaires de premier plan, tout aussi engagés que nous en faveur de la protection de la confidentialité.
L'un des éléments essentiels de ce protocole repose sur un proxy découplé du résolveur cible. Nous annonçons donc aujourd'hui le lancement du protocole ODoH en collaboration avec plusieurs grands partenaires de mise en proxy, notamment PCCW, SURF et Equinix.
« Le protocole ODoH représente un nouveau concept révolutionnaire, conçu pour placer la vie privée des utilisateurs au centre de toutes nos activités. Notre partenariat avec Cloudflare dans le cadre d'ODoH nous positionne bien sur le secteur de la confidentialité et de « l'infrastructure de l'Internet ». Outre l'accroissement de la sécurité et des performances du réseau mondial sous-jacent de PCCW (accessible à la demande via Console Connect), les performances des proxys de notre réseau se voient également améliorées par les résolveurs 1.1.1.1 de Cloudflare. Pour la première fois, ce modèle découple complètement le proxy client des résolveurs. Ce partenariat renforce l'accent que nous plaçons déjà sur le respect de la vie privée dans un monde se dirigeant vers un modèle plus distant et au sein duquel la confidentialité devient une fonctionnalité toujours plus essentielle. » — Michael Glynn, vice-président chargé de l'innovation numérique automatisée, PCCW Global
« Nous travaillons en partenariat avec Cloudflare afin de mettre en place de meilleures mesures de respect de la vie privée des utilisateurs à l'aide du protocole ODoH. La transition vers ODoH constitue un véritable changement de paradigme, au sein duquel aucun fournisseur n'aura accès aux informations personnelles ou à l'adresse IP des utilisateurs, entraînant ainsi une véritable protection de la confidentialité. Avec le lancement du pilote OdoH, nous rejoignons la puissance du réseau de Cloudflare afin de répondre aux problèmes de tous les utilisateurs à travers le monde. La transition vers ODoH ne représente pas uniquement un changement de paradigme, elle insiste également sur l'importance toute particulière que revêt la confidentialité pour les utilisateurs, surtout en 2020. Ce protocole fait écho à nos convictions fondamentales en matière de respect de la confidentialité. » — Joost van Dijk, responsable technique des produits, SURF
Comment fonctionne l'Oblivious DNS over HTTPS (ODoH) ?
Le protocole ODoH repose sur l'ajout d'une couche de chiffrement par clé publique, ainsi que d'un proxy réseau entre les clients et les serveurs DoH, comme le résolveur 1.1.1.1. L'association de ces deux éléments ajoutés garantit que seul l'utilisateur peut avoir accès en même temps à la fois aux messages DNS et à sa propre adresse IP.
Le chemin du protocole ODoH se compose de trois acteurs. En regardant la figure ci-dessus, commençons par la cible. La cible déchiffre les requêtes chiffrées par le client à l'aide d'un proxy. De même, la cible chiffre les réponses et les renvoie au proxy. La norme indique si la cible peut ou non être le résolveur (nous y reviendrons plus tard). Le proxy remplit son office, à savoir transmettre des messages entre le client et la cible. Le client fonctionne comme dans le protocole DNS et DoH, mais son comportement diffère en ce qu'il chiffre les requêtes pour la cible et déchiffre les réponses de cette dernière. Un client peut spécifier un proxy et une cible de son choix s'il choisit de le faire.
Ensemble, le chiffrement et la mise en proxy permettent de proposer 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 et aucune capacité d'identifier, lire ou modifier la requête envoyée par le client ou la réponse renvoyée par la cible.
- Seul le système cible concerné peut lire le contenu de la requête et produire une réponse.
Ces trois garanties améliorent la confidentialité du client, tout en préservant la sécurité et l'intégrité des requêtes DNS. Toutefois, chacune de ces garanties repose sur une propriété fondamentale : le proxy et les serveurs cibles n'entrent pas en collusion. Sauf collusion, un pirate ne peut arriver à ses fins que si le proxy et la cible sont tous deux compromis.
L'un des aspects de ce système méritant d'être souligné réside dans le fait que la cible s'avère distincte du résolveur récursif qui effectue la résolution DNS en amont. En pratique, dans une optique de performances, nous nous attendons toutefois à ce qu'ils soient identiques. En fait, le résolveur 1.1.1.1 est désormais à la fois une cible et un résolveur récursif ! Aucune raison ne justifie qu'une cible doive exister séparément d'un résolveur. Lorsqu'ils sont distincts, toutefois, la cible est libre de choisir les résolveurs et de servir d'intermédiaire. La seule exigence réelle, souvenez-vous, c'est qu'il n'y ait jamais collusion entre le proxy et la cible.
Par ailleurs, il est important de remarquer que les clients disposent d'un contrôle total sur la sélection du proxy et de la cible. Sans programme de type TRR, les clients peuvent bénéficier de requêtes confidentielles, en plus d'être sécurisées. Comme la cible ne connaît que le proxy, la cible et les éventuels résolveurs en amont ignorent l'existence des adresses IP des clients. L'important, c'est que les clients disposent ainsi d'un meilleur contrôle sur leurs requêtes et la manière dont elles peuvent être utilisées. Ils peuvent, par exemple, sélectionner et modifier leurs proxys et leurs cibles à tout moment, et ce pour n'importe quelle raison !
Flux des messages ODoH
Dans l'acronyme ODoH, la lettre « O » signifie « Oblivious » (aveugle), soit une propriété venant du chiffrement des messages DNS eux-mêmes. Présent « de bout en bout » entre le client et la cible, ce niveau de chiffrement supplémentaire reste indépendant du chiffrement au niveau de la connexion fourni par le protocole TLS/HTTPS. Il serait légitime de s'interroger sur la nécessité de ce chiffrement supplémentaire en présence d'un proxy. La raison en est que 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 originaire du client et lance une autre connexion TLS vers la cible. Autrement, les contextes des messages DNS entre ces deux connexions seraient diffusés en clair ! Le protocole ODoH ajoute ainsi un niveau de chiffrement supplémentaire aux messages transmis entre le client et la cible, de sorte que le proxy n'a pas accès au contenu du message.
Le processus dans son ensemble commence avec le chiffrement par les clients de la requête vers la cible à l'aide de la méthode HPKE. Les clients obtiennent alors la clé publique de la cible via le DNS, regroupée sous forme d'un enregistrement de ressources HTTPS et protégée à l'aide du protocole DNSSEC. Lorsque le TTL de cette clé expire, les clients demandent une nouvelle copie de la clé au besoin (comme ils le feraient pour un enregistrement A/AAAA à expiration du TTL de cet enregistrement). L'utilisation d'une clé publique validée par DNSSEC spécifique à la 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 vers un proxy par l'intermédiaire d'une connexion HTTPS. À réception, le proxy transmet la requête à la cible désignée. La cible déchiffre alors la requête, génère une réponse en envoyant la requête à un résolveur récursif, comme le 1.1.1.1, puis chiffre la réponse transmise au client. La requête chiffrée provenant du client contient des informations (encapsulées) de compilation de clé depuis lesquelles les cibles dérivent la clé symétrique de la clé de chiffrement de la réponse.
Cette réponse est ensuite renvoyée au proxy, puis transmise au client. Toutes les communications sont authentifiées et confidentielles, car ces messages DNS sont chiffrés de bout en bout, bien qu'ils soient transmis via deux connexions HTTPS distinctes (client-proxy et proxy-cible). Le message qui apparaît par ailleurs au proxy sous forme de texte en clair ne constitue en fait qu'une déformation chiffrée.
Qu'en est-il des performances ? Dois-je les sacrifier à la confidentialité ?
Nous avons effectué de nombreuses mesures pour le découvrir et nous en réaliserons d'autres pendant le déploiement du protocole ODoH à une plus vaste échelle. Notre première série de mesures concernait des villes situées aux États-Unis, au Canada et au Brésil. Fait notable, nos mesures portent non seulement sur le résolveur 1.1.1.1, mais aussi sur les résolveurs 8.8.8.8 et 9.9.9.9. À ce jour, l'ensemble complet des mesures est disponible en accès libre.
Dans ces mesures, il était important d'isoler le coût de la mise en proxy et du chiffrement supplémentaire du coût de la mise en place des connexions TCP et TLS, car ces derniers coûts sont pris en charge par le protocole DoH, dans tous les cas. Ainsi, pour notre installation, nous avons « amorcé » les mesures en établissant une connexion une première fois et en réutilisant cette dernière pour l'ensemble des mesures. Nous avons suivi cette approche à la fois pour le protocole DoH et l'ODoH, puisque la même stratégie pouvait être utilisée dans les deux cas.
La première conclusion que nous pouvons tirer en toute confiance, c'est que l'apport du chiffrement supplémentaire est marginal. Nous sommes arrivés à ce résultat après avoir sélectionné au hasard 10 000 domaines du Tranco Million Dataset et mesuré à la fois le chiffrement de l'enregistrement A avec une clé publique différente, ainsi que son déchiffrement. Le coût supplémentaire entre une requête/réponse DoH mise en proxy et son homologue au protocole ODoH est systématiquement inférieur à 1 ms dans 99 % des cas.
Le pipeline requête/réponse ODoH constitue toutefois bien plus qu'un simple chiffrement. Une manière très utile d'examiner les mesures consiste à examiner le graphique de distribution cumulée. Passez directement au paragraphe suivant si vous connaissez déjà ce type de graphique. Contrairement à la plupart des graphiques, dont l'analyse suit l'axe des abscisses, l'analyse des distributions cumulées commence souvent par l'axe des ordonnées.
Le graphique ci-dessous montre les distributions cumulées des temps de requête/réponse pour les protocoles DoH, ODoH et DoH transmis sur le réseau Tor. La ligne horizontale pointillée d'une valeur de 0,5 indique la marque des 50 %. En suivant cette ligne horizontale, la partie d'une courbe située sous la ligne pointillée sur le graphique représente 50 % des points de données. Intéressons-nous maintenant l'axe des abscisses, qui représente une mesure du temps. Les courbes situées à gauche sont ainsi plus rapides que celles de droite. Dernier détail important : l'axe des abscisses est rendu selon une échelle logarithmique. Qu'est-ce que cela signifie ? Vous remarquerez que la distance entre les marqueurs notés (10x) est égale pour les distributions cumulatives, mais le « x » constitue un exposant et représente des ordres de grandeur. Ainsi, alors que les deux premiers marqueurs affichent une différence temporelle de 9 ms, la différence entre le troisième et le quatrième marqueur est de 900 ms.
Dans ce graphique, la courbe médiane représente les mesures ODoH. Nous avons également mesuré les performances des autres solutions de préservation de la confidentialité, par exemple, les requêtes DoH transmises via le réseau Tor, représentées par la courbe de droite dans le graphique. (Vous trouverez les courbes d'autres solutions de préservation de la vie privée dans le rapport technique disponible en accès libre.) Comparativement à d'autres variantes DNS axées sur la confidentialité, le protocole ODoH réduit le temps de requête de moitié, voire moins. Il s'agit là d'un point important, car la confidentialité et les performances vont rarement de pair, aussi constater ce type d'amélioration s'avère plutôt encourageant !
Le graphique ci-dessus nous indique également que 50 % des requêtes ODoH sont résolues en moins de 228 ms. Comparons maintenant la courbe du milieu à la courbe de gauche, qui représente la « ligne droite » (ou normale) du protocole DoH sans aucune modification. La courbe de gauche montre que dans 50 % des cas, les requêtes DoH sont résolues en moins de 146 ms. Si l'on examine leur partie située sous la barre des 50 %, les courbes nous indiquent également que cette différence n'est jamais supérieure à 100 ms la moitié du temps. De l'autre côté, en considérant la partie des courbes située au-dessus de la barre des 50 %, on constate que la moitié des requêtes ODoH restent sur le même plan que celles du protocole DoH.
Ces courbes dissimulent également beaucoup d'informations, il est donc important d'aller plus loin dans les mesures. Le graphique ci-dessous présente trois courbes de distribution cumulées différentes décrivant les performances du protocole ODoH en cas de sélection des proxys et des cibles en fonction de leur latence. Il s'agit également là d'un exemple des informations que les mesures sont susceptibles de révéler, certaines s'avérant d'ailleurs contre-intuitives. Par exemple, si l'on s'intéresse à leur partie située au-dessus de la valeur 0,5, ces courbes indiquent que la moitié des temps de requête/réponse ODoH restent pratiquement indiscernables, quels que soient la cible et le proxy sélectionnés. Reportons maintenant notre attention sur la partie située sous la valeur 0,5 et comparons les deux courbes pleines à la courbe pointillée représentant la moyenne générale. Cette zone suggère que la sélection d'un proxy et d'une cible affichant la plus faible latence possible présente une amélioration minimale par rapport à la moyenne. Toutefois, plus important encore, elle montre que la sélection du proxy présentant la plus faible latence conduit à des performances inférieures !
Bien entendu, certaines questions restent ouvertes. Cette première série de mesures a été réalisée en grande partie en Amérique du Nord. Les performances sont-elles différentes à l'échelle mondiale ? En quoi ces résultats affectent-ils les performances des clients en pratique ? Nous nous efforçons de répondre à ces questions et cette version nous aidera à le faire.
Intéressant ! Puis-je tester le protocole ODoH ? Existe-t-il un service ODoH ouvert ?
Oui et oui ! Nous proposons nos implémentations ODoH interopérables en open source dans Rust, odoh-rs et Go, odoh-go. Nous avons également intégré la cible dans le résolveur DNS de Cloudflare. C'est exact, le résolveur 1.1.1.1 est prêt à recevoir des requêtes par l'intermédiaire du protocole ODoH.
Nous proposons également des clients de test en open source dans Rust, odoh-client-rs et Go, odoh-client-go, afin de tester les requêtes ODoH. Vous pouvez également consulter la configuration HPKE utilisée par le protocole ODoH pour le chiffrement des messages vers le résolveur 1.1.1.1 en interrogeant directement le service :
$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com. IN TYPE65
;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300 IN TYPE65 \# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300 IN RRSIG TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==
;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE rcvd: 291
Nous sommes déterminés à promouvoir cette norme au sein de l'IETF. Nous espérons que d'autres opérateurs nous rejoindront en cours de route et offriront une prise en charge du protocole, en déployant des proxys ou des cibles. De même, nous espérons que la prise en charge de clients augmentera au fur et à mesure que l'infrastructure disponible se développera, elle aussi.
Le protocole ODoH constitue une approche pratique de l'amélioration de la confidentialité des données des utilisateurs. Il vise également à améliorer l'adoption générale des protocoles DNS chiffrés, sans compromettre les performances et l'expérience utilisateur sur Internet.
Remerciements
Marek Vavruša et Anbang Wen ont grandement contribué à amener le résolveur 1.1.1.1 à prendre en charge le protocole ODoH. Chris Wood et Peter Wu nous ont aidés à préparer et tester les bibliothèques ODoH.