Développeurs de Firefox concernant la fin des tests de support DNS sur HTTPS (DoH, DNS over HTTPS) et l'intention de l'activer par défaut pour les utilisateurs aux États-Unis à la fin septembre. L'activation se fera progressivement, d'abord pour quelques pourcentages d'utilisateurs, et en l'absence de problèmes, sera étendue jusqu'à 100 %. Une fois les États-Unis couverts, la possibilité d'activer DoH dans d'autres pays sera envisagée.
Les tests menés au cours de l'année ont montré la fiabilité et de bonnes performances du service, tout en permettant d'identifier certaines situations où DoH peut poser des problèmes, et de développer des solutions pour les contourner (par exemple, optimisé en ce qui concerne l'optimisation du trafic dans les réseaux de livraison de contenu, le contrôle parental et les zones DNS internes d'entreprise).
L'importance du chiffrement du trafic DNS est considérée comme un facteur de protection des utilisateurs, c'est pourquoi il a été décidé d'activer DoH par défaut, mais dans un premier temps uniquement pour les utilisateurs aux États-Unis. Après l'activation de DoH, un avertissement sera donné à l'utilisateur, lui permettant, s'il le souhaite, de renoncer à l'utilisation des serveurs DNS DoH centralisés et de revenir à l'ancien schéma d'envoi de requêtes non chiffrées au serveur DNS du fournisseur (au lieu de l'infrastructure distribuée de résolveurs DNS, DoH utilise une liaison à un service DoH spécifique, qui peut être considéré comme un point unique de défaillance).
Avec l'activation de DoH, il est possible que le fonctionnement des systèmes de contrôle parental et des réseaux d'entreprise utilisant une structure de noms DNS accessible uniquement pour le réseau interne pour la conversion des adresses intranet et des hôtes d'entreprise soit perturbé. Pour résoudre les problèmes liés à de tels systèmes, un système de vérifications a été ajouté, désactivant automatiquement DoH. Les vérifications sont effectuées à chaque lancement du navigateur ou lors de la détection d'un changement de sous-réseau.
Un retour automatique à l'utilisation du résolveur par défaut du système d'exploitation est également prévu en cas d'échecs lors de la résolution via DoH (par exemple, en cas de rupture de la disponibilité réseau avec le fournisseur DoH ou en cas d'échecs dans son infrastructure). Le sens de telles vérifications est discutable, car rien n'empêche un attaquant, contrôlant le fonctionnement du résolveur ou capable d'interférer dans le trafic, de simuler un tel comportement pour désactiver le chiffrement du trafic DNS. Le problème est résolu par l'ajout d'un point de configuration « DoH toujours » (non activé par défaut), dont l'activation empêche la désactivation automatique, ce qui représente un compromis raisonnable.
Pour identifier les résolveurs d'entreprise, des vérifications sont effectuées sur les domaines de premier niveau (TLD) atypiques et le retour des adresses intranet par le résolveur système. Pour déterminer l'activation du contrôle parental, une tentative de résolution du nom exampleadultsite.com est effectuée, et si le résultat ne correspond pas à l'IP réelle, il est considéré que le blocage de contenu pour adultes est actif au niveau DNS. Des vérifications sont également effectuées sur les adresses IP de Google et YouTube concernant leur substitution par restrict.youtube.com, forcesafesearch.google.com et restrictmoderate.youtube.com. De plus, Mozilla implémenter un hôte de vérification unifié , qui peut être utilisé par les fournisseurs d'accès Internet et les services de contrôle parental comme marqueur pour désactiver DoH (si l'hôte n'est pas déterminé, Firefox désactive DoH).
Travailler via un service DoH unique peut également entraîner des problèmes d'optimisation du trafic dans les réseaux de distribution de contenu, qui effectuent l'équilibrage du trafic en utilisant DNS (le serveur DNS du CDN génère une réponse en tenant compte de l'adresse du résolveur et fournit le serveur le plus proche pour récupérer le contenu). En envoyant une requête DNS depuis le résolveur le plus proche de l'utilisateur dans ces CDN, on renvoie l'adresse de l'hôte le plus proche de l'utilisateur. En revanche, en envoyant une requête DNS depuis un résolveur centralisé, l'adresse renvoyée sera celle de l'hôte le plus proche du serveur DNS-over-HTTPS. Des tests pratiques ont montré que l'utilisation de DNS-over-HTTP avec CDN n'a pratiquement pas entraîné de retards avant le début de la transmission du contenu (pour les connexions rapides, les retards n'ont pas dépassé 10 millisecondes, et sur des canaux de communication lents, une accélération a même été observée). Pour transmettre au résolveur CDN des informations sur la localisation du client, l'utilisation de l'extension EDNS Client Subnet a également été envisagée.
Rappelons que DoH peut être utile pour éviter les fuites d'informations sur les noms d'hôtes demandés via les serveurs DNS des fournisseurs, lutter contre les attaques MITM et la substitution du trafic DNS, contrer les blocages au niveau DNS ou pour organiser le fonctionnement en cas d'impossibilité d'accès direct aux serveurs DNS (par exemple, lors du travail via un proxy). Si, dans une situation normale, les requêtes DNS sont envoyées directement aux serveurs DNS spécifiés dans la configuration système, alors dans le cas de DoH, la requête pour déterminer l'adresse IP de l'hôte est encapsulée dans le trafic HTTPS et envoyée à un serveur HTTP, où le résolveur traite les requêtes via Web API. La norme existante DNSSEC utilise le chiffrement uniquement pour l'authentification du client et du serveur, mais ne protège pas le trafic contre l'interception et ne garantit pas la confidentialité des requêtes.
Pour activer DoH dans about:config, il faut modifier la valeur de la variable network.trr.mode, prise en charge à partir de Firefox 60. La valeur 0 désactive complètement DoH ; 1 utilise DNS ou DoH, en fonction de ce qui est le plus rapide ; 2 utilise DoH par défaut, avec DNS comme option de secours ; 3 utilise uniquement DoH ; 4 est le mode de miroir où DoH et DNS sont utilisés en parallèle. Par défaut, le serveur DNS de CloudFlare est utilisé, mais il peut être modifié via le paramètre network.trr.uri, par exemple, vous pouvez définir « https://dns.google.com/experimental » ou « https://9.9.9.9/dns-query ».
Source : opennet.ru
