Gardez-le crypté, gardez-le en sécurité : Travailler avec ESNI, DoH et DoT

Les derniers développements en matière de protection de la vie privée sur Internet incluent l'indication de nom de serveur TLS cryptée (ESNI) et le DNS crypté sous la forme de DNS sur HTTPS (DoH), qui sont tous deux considérés comme très controversés par les collecteurs de données.

Voici donc un bref aperçu des raisons pour lesquelles ils existent, des détails sur ce qu'ils sont et de la technologie derrière leur fonctionnement.

Le DNS doit fonctionner correctement

Les connexions de réseau privé virtuel (VPN) à tunnel divisé, le protocole de découverte automatique de proxy Web (WPAD), le DNS multidiffusion sans configuration (mDNS), les listes noires en temps réel (RBL) et de nombreuses autres technologies largement déployées se cassent lorsque le DNS ne fonctionne pas. t fonctionner correctement.

Briser Internet pour le profit et la renommée

Dès 2003, les internautes ont pris conscience de l'importance du DNS à l'échelle mondiale lorsque la société qui gérait alors le domaine de premier niveau (TLD) .com a choisi d'arrêter d'émettre des réponses NXDOMAIN . Au lieu de cela, ils se sont fait passer pour n'importe quel domaine inexistant dans le but de diffuser plus d'annonces, de vendre plus de domaines et, en fin de compte, de générer plus de revenus. L'effet d'entraînement imprévu a donné lieu à un débat public et à un rapport accablant du comité consultatif sur la sécurité et la stabilité (SSAC) de l'ICANN. Ce projet a effectivement été arrêté mais d'un point de vue technique, la vulnérabilité persistait.

Plus tard en 2008, une autre tentative de manipulation du DNS à des fins lucratives a été dénoncée publiquement lorsque certains des plus grands FAI ont fini par introduire diverses voies d'attaques par script intersite contre littéralement n'importe quel site Web. En raison de la nature des vulnérabilités, même les sites Web hébergés sur un réseau privé et inaccessibles depuis Internet peuvent être exploités.

Le problème trouvé ne concerne pas les protocoles Internet de base, mais plutôt un problème exacerbé par une monétisation inappropriée de certaines fonctionnalités DNS.

Paul Vixie, Consortium des systèmes Internet (ISC)

S'il est vrai que les protocoles eux-mêmes ne sont pas vraiment la cause du problème, il est également vrai que ces protocoles n'empêchent pas les mauvais acteurs d'abuser du système. Donc d'un point de vue technique, la vulnérabilité persistait.

Briser Internet pour la surveillance et la censure

En 2016, il a été observé que les FAI en Iran manipulaient le DNS. Cette fois, au lieu d'injecter des publicités, ils bloquaient l'accès aux serveurs de messagerie de 139 des 10 000 meilleurs domaines sur Internet. Il n'est pas clair s'il s'agit d'une politique intentionnelle de déni de service contre ces domaines spécifiques - similaire à la censure de renommée mondiale en Chine - ou peut-être simplement un exemple d'une mauvaise implémentation technique de tout système interceptant les requêtes DNS.

Il est important de ne pas savoir pourquoi le DNS est intercepté : même si nous mettons de côté les questions morales et juridiques sur la surveillance générale et la censure, la technologie utilisée pour ce faire n'est, de par sa nature même, pas conforme aux normes et pourrait très bien interférer avec votre utilisation normale, quotidienne, raisonnable et légale d'Internet.

Pourtant, d'un point de vue technique, la vulnérabilité persistait.

Briser Internet à des fins néfastes

Bien sûr, ce ne sont pas seulement les entités commerciales et les gouvernements qui tentent d'intercepter le trafic Internet pour leurs propres moyens. Il existe de nombreux exemples de criminels tentant de détourner des connexions, généralement dans le but de voler des données utilisateur ou d'inciter les utilisateurs à révéler des informations d'identification d'accès importantes. Plus important encore, l'empoisonnement du cache DNS a été utilisé pour diriger les utilisateurs vers des sites de phishing, déployer des ransomwares, déployer des botnets, refuser le service à des sites Web spécifiques, et bien plus encore.

TLS Leaks Qui se connecte à qui

Transport Layer Security (TLS) est la technologie derrière HTTPS, la version sécurisée de HTTP sur laquelle nous comptons tous au quotidien. L'établissement d'une connexion TLS nécessite un certain nombre d'étapes, au cours desquelles le serveur prouve son identité en présentant un certificat, et de nouvelles clés de chiffrement sont échangées.

Faire en sorte que le serveur utilise un certificat pour prouver son identité est une étape très importante, car une partie du certificat est une clé de cryptage publique asymétrique.

Lorsque le client envoie un message en utilisant cette clé, seul le serveur qui est en possession de la clé privée associée peut lire le message. En conséquence, toute personne interceptant ou écoutant la connexion est verrouillée et incapable de lire le contenu.

Cependant, cet échange initial se fait toujours en clair sans cryptage, ce qui signifie qu'un observateur connaîtra toujours l'identité du serveur.

Façade de domaine

Quelques outils de type anti-censure ont contourné cette fuite dans TLS pendant un certain temps en utilisant une technique connue sous le nom de façade de domaine. Cela exploite le fait qu'une fois qu'une connexion HTTPS est établie, la plupart des grands hébergeurs ne vérifient pas si le nom d'hôte présenté dans chaque requête HTTP correspond à celui utilisé dans la poignée de main TLS. En termes d'outils de confidentialité, cela a été considéré comme une fonctionnalité utile permettant une communication secrète avec un site caché. Pour les fournisseurs d'hébergement et les collecteurs de données, cela a été considéré comme un abus de la manière dont la spécification a été mise en œuvre.

Il s'agit en soi d'une vulnérabilité et, en tant que telle, elle a été corrigée par plusieurs grands fournisseurs d'hébergement, dont AWS.

Résoudre le problème en modifiant la norme : SNI crypté (ESNI)

L'idée derrière ESNI est d'empêcher TLS de divulguer des données en chiffrant tous les messages, y compris le message initial Client Hello . Cela laisse tout observateur complètement dans l'ignorance du certificat de serveur présenté par le serveur.

Pour ce faire, le client a besoin d'une clé de chiffrement avant d'établir la connexion. Par conséquent, ESNI exige qu'un ensemble spécifique de clés de chiffrement ESNI soit placé dans un enregistrement SRV dans DNS.

Les détails exacts de ceci sont toujours en cours, cependant, car la spécification n'est pas encore finalisée. Malgré cela, une implémentation d'ESNI a déjà été mise en production par Mozilla Firefox et Cloudflare.

Sécuriser et chiffrer le DNS

Pour que les clés ESNI soient livrées sans être interceptées, il est important de se protéger contre la falsification DNS.

Depuis 1993, la communauté Internet tente de sécuriser le DNS. L'IETF note que les premières réunions de résolution de problèmes ont discuté :

1. Protection contre la divulgation de données DNS à des tiers non autorisés
2. Assurer l'intégrité des données
3. Authentification de l'origine des données

Ces réunions ont abouti à la norme DNSSEC (Domain Name System Security Extensions) en 1997. La norme a choisi de répondre à deux de ces préoccupations sur trois, car l'équipe de conception a pris la décision explicite d'exclure explicitement toutes les menaces de divulgation de données.

En tant que tel, DNSSEC signifie que les utilisateurs peuvent être sûrs que les réponses à leurs requêtes DNS correspondent à ce que les propriétaires de domaine souhaitent qu'elles soient. Dans le contexte d'ESNI, cela signifie que nous savons que la clé que nous recevons n'a pas été falsifiée et, heureusement, de nombreuses vulnérabilités mentionnées ci-dessus disparaissent lorsque DNSSEC est utilisé. Cependant, il ne garantit pas la confidentialité et reste donc vulnérable aux problèmes introduits par les systèmes de surveillance et de censure.

Malheureusement, comme il est entièrement rétrocompatible avec le « DNS non sécurisé » et assez difficile à mettre en œuvre correctement, l'adoption de DNSSEC est très faible. De nombreux propriétaires de domaine abandonnent à mi-chemin en essayant de le configurer, comme en témoignent de nombreuses configurations invalides et à moitié configurées observées dans la nature.

DNS sur HTTPS (DoH)

Pour que les clés ESNI soient délivrées sans que les observateurs sachent quels utilisateurs du site tentent de visiter, il est important de se protéger contre les écoutes DNS. En tant que tel, il est tout à fait logique et compréhensible de dire que le DNS crypté (comme avec DoH) est une bonne chose. Pourtant, dans l'état actuel des choses, le DNS n'est pas crypté.

Mozilla, Google, APNIC, Cloudflare, Microsoft et d'autres ont pris des mesures pour changer cela.

L'expérience utilisateur cryptée idéale

Un utilisateur souhaitant tirer parti des technologies ci-dessus peut avoir une liste assez longue d'exigences en ce qui concerne les détails pratiques UX de l'utilisation du chiffrement. Probablement, ils voudraient éviter les goûts de :

• Être obligé d'utiliser un fournisseur de services DNS spécifique (aussi bon soit-il) ou pour le choix d'être invisible ou difficile à trouver
• Chaque application sur un appareil gère le DNS différemment (par exemple, Firefox peut trouver des choses que Safari ne peut pas)
• Toutes les applications sur un appareil doivent créer leur propre implémentation DNS sécurisée en eux-mêmes
• Devoir configurer manuellement le DNS plusieurs fois
• Devoir opter pour la confidentialité et la sécurité
• Applications retombant dans un fonctionnement non sécurisé sans le consentement de l'utilisateur

Les utilisateurs soucieux de leur vie privée souhaiteraient plutôt :

• Confidentialité contre la surveillance injustifiée de quiconque
• Protection contre la publicité ciblée à laquelle ils n'ont pas consenti
• Protection de leur propre contenu publié (par exemple, sur un site Web personnel) contre toute modification ou manipulation en cours de route vers d'autres téléspectateurs
• L'assurance que les téléspectateurs de leur propre contenu publié n'auront pas de problèmes simplement pour y accéder
• Pour continuer à avoir la possibilité de contrôler le DNS sur leurs propres réseaux (parce que parfois, le DNS à horizon partagé est bon pour garder les ressources internes limitées aux utilisateurs internes)
• La possibilité d'activer ou au moins de désactiver le filtrage au niveau DNS (par exemple, Quad9, CleanBrowsing et OpenDNS Family Shield)
• Configuration facile et sans tracas (c.-à-d. DHCP)
• Être invité à consentir à l'utilisation de DNS sans cryptage
• Protection non seulement pour le trafic du navigateur, mais pour tous les types de trafic, par exemple, e-mail, Slack, VoIP, SSH, VPN, etc.

Efforts de chiffrement actuels

Quelles sont les options disponibles pour les utilisateurs ayant les objectifs ci-dessus ?

La solution de Mozilla est un début, mais loin d'être idéale. Ils ne sécurisent que Firefox ; la valeur par défaut est de remplacer les paramètres de votre système d'exploitation en faveur de leur choix de fournisseur (Cloudflare) sans le dire, et il retombe silencieusement dans l'insécurité (en cas de blocage du DNS crypté, etc.)

La solution de Google est une meilleure approche. Ils sécurisent Android 9+, qui s'applique à toutes les applications. (Je ne suis pas sûr de leurs plans pour Chrome OS, mais je suppose que c'est en cours.) Ils sécurisent également Chrome sur toutes les plates-formes, mais cela ne déclenche la sécurité que lorsque la plate-forme hôte est configurée pour utiliser un fournisseur qui prend en charge la sécurité. C'est bon en termes de choix de l'utilisateur, mais pas idéal car il retombe silencieusement dans l'insécurité.

Tous les autres principaux navigateurs implémentent également la prise en charge.

Dans la situation idéale pour les utilisateurs, la communauté élargie des développeurs de logiciels et de systèmes d'exploitation :

1. Arrêtez d'implémenter de nouvelles fonctionnalités de sécurité DNS au niveau de l'application
2. Commencez à les implémenter au niveau du système d'exploitation
3. Respectez la configuration au niveau du système d'exploitation ou obtenez le consentement de l'utilisateur

En implémentant le DNS crypté au niveau du système d'exploitation, nous pourrions continuer à suivre le même modèle distribué que nous avons actuellement pour les résolveurs DNS. Exécuter son propre serveur DNS sur son propre réseau et pouvoir sécuriser ce résolveur est logique de continuer à être une option, tout comme l'utilisation d'un fournisseur centralisé.

Linux et BSD ont déjà cette fonctionnalité avec une variété d'options disponibles. Malheureusement, aucune distribution n'en active aucune par défaut, pour autant que je sache. Consultez nss-tls si vous voulez quelque chose qui se branche simplement sur glibc.

L'implémentation DNS sur TLS de Google dans Android 9+ le fait également déjà. Il fonctionne en testant le serveur DNS pour la prise en charge du chiffrement. S'il l'a, il l'utilisera. Si ce n'est pas le cas, alors, comme avec Chrome, il continue de manière non sécurisée, sans demander le consentement.

Il convient de noter que la plupart des réseaux sont configurés pour utiliser des serveurs DNS qui ne prennent pas en charge le cryptage, de sorte que la solution intégrée à Android ne change encore rien pour la plupart des utilisateurs. Peut-être serait-il préférable de proposer de se rabattre sur un DNS crypté centralisé dans les cas où le décentralisé ne prend pas en charge le cryptage.

Pour les appareils Apple et Microsoft, la prise en charge du DNS crypté n'est pas encore officiellement arrivée au moment de la rédaction de cet article. Microsoft ayant annoncé en novembre 2019 son intention de prendre en charge le DNS crypté, nous espérons qu'Apple suivra bientôt.

Solutions de contournement DNS cryptées

Il existe des solutions de contournement sous la forme de proxys pouvant être exécutés localement. Avec ceux-ci, l'ordinateur d'un utilisateur se communique un DNS non crypté, qui communique ensuite un DNS crypté au fournisseur qu'il est configuré pour utiliser. Ce n'est pas une solution idéale, mais comme solutions de contournement, c'est décent.

L'inspiration pour écrire cet article est le proxy DNSCrypt, qui est très stable, a beaucoup de cloches et de sifflets et est multiplateforme. Il prend en charge l'ancien protocole DNSCrypt, ainsi que les nouveaux protocoles DNS sur TLS (DoT) et DNS sur HTTPS (DoH).

Pour les utilisateurs de Windows, il existe un programme d'installation et une interface graphique appelés Simple DNSCrypt, qui sont complets et très faciles à utiliser.

Je le recommande, mais sachez que le monde n'est probablement pas encore prêt pour vous et que vous devrez peut-être le désactiver de temps en temps (par exemple, lorsque vous devez utiliser un portail captif dans votre café préféré ou sur un LAN fête).

Autres options

De plus, il existe le serveur DNS Technitium, qui prend en charge le DNS crypté, est multiplateforme (Windows, MacOS, Linux sur ARM/Raspberry Pi) et dispose d'une interface Web élégante. C'est sous "autre" parce que c'est plus un outil complet qu'une solution spécifique à ce problème. (Ce serait probablement un bon choix si vous souhaitez exécuter votre serveur DNS Raspberry Pi à la maison. Je serais intéressé d'entendre les commentaires des personnes qui l'ont essayé dans les commentaires ci-dessous.)

Pour vos appareils Android ou iOS (iPhone, iPad, etc.), il existe également l'application 1.1.1.1, qui forcera toutes vos requêtes DNS sur le service Cloudflare Encrypted DNS. J'entends dire qu'il existe également des applications plus flexibles, comme Intra, mais je n'ai pas encore passé le temps de les tester.

Bien sûr, vous pouvez également activer le DNS crypté dans Firefox et Chrome - gardez simplement à l'esprit toutes les mises en garde décrites ci-dessus.

Fiabilité DNS : tâche numéro un

Il y a beaucoup de controverse avec la technologie de confidentialité sur Internet. Cependant, lorsqu'il s'agit de mettre en œuvre des mesures de sécurité et de confidentialité, la technologie en question ne consiste pas principalement à garder des secrets. Il s'agit d'assurer la fiabilité et de garantir que la technologie continue de fonctionner correctement malgré le comportement des autres. Pourtant, nous devons garder à l'esprit que, tout comme une technologie sans protection de la vie privée est mauvaise, des protections mal mises en œuvre ne peuvent qu'aggraver la situation.