Développeurs de Firefox concernant l'activation par défaut du mode DNS sur HTTPS (DoH, DNS over HTTPS) pour les utilisateurs des États-Unis. Le chiffrement du trafic DNS est considéré comme un facteur crucial pour la protection des utilisateurs. À partir d'aujourd'hui, dans toutes les nouvelles installations effectuées par des utilisateurs des États-Unis, DoH est activé par défaut. Les utilisateurs existants aux États-Unis seront transférés vers DoH dans quelques semaines. Dans l'Union Européenne et d'autres pays, l'activation de DoH par défaut n'est pas encore prévue. .
Après l'activation de DoH, un avertissement s'affiche pour permettre à l'utilisateur de choisir de ne pas se connecter aux serveurs DNS DoH centralisés et de revenir à l'ancienne méthode d'envoi de requêtes non chiffrées au serveur DNS de l'opérateur. Au lieu d'une infrastructure distribuée de résolveurs DNS, DoH est lié à un service DoH spécifique, qui peut être considéré comme un point unique de défaillance. Actuellement, il est possible d'utiliser deux fournisseurs DNS — CloudFlare (par défaut) et .
Changer de fournisseur ou désactiver DoH dans les paramètres de la connexion réseau. Par exemple, il est possible de spécifier un serveur DoH alternatif «https://dns.google/dns-query» pour accéder aux serveurs de Google, «https://dns.quad9.net/dns-query» pour Quad9, et «https://doh.opendns.com/dns-query» pour OpenDNS. Dans about:config, il est également prévu de configurer network.trr.mode, qui permet de changer le mode de fonctionnement de DoH : une valeur de 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 en option ; 3 utilise uniquement DoH ; 4 active le mode de réflexion où DoH et DNS sont utilisés simultanément.
Rappelons que le DoH peut s'avérer utile pour éviter les fuites d'informations sur les noms d'hôtes demandés via les serveurs DNS des fournisseurs, pour lutter contre les attaques MITM et le traffic DNS spoofing (par exemple, lors de la connexion à des Wi-Fi publics), pour contrer les blocages au niveau de DNS (le DoH ne peut pas remplacer un VPN en matière de contournement des blocages mis en place au niveau du DPI) ou pour organiser le fonctionnement en cas d'impossibilité d'un accès direct aux serveurs DNS (par exemple, lorsqu'on passe par un proxy). Dans une situation normale, les requêtes DNS sont directement envoyées aux serveurs DNS spécifiés dans la configuration du système, alors qu'avec le 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 une API Web. La norme existante DNSSEC utilise le cryptage uniquement pour authentifier le client et le serveur, mais ne protège pas le trafic contre l'interception et ne garantit pas la confidentialité des requêtes.
Des exigences ont été formulées pour sélectionner les fournisseurs DoH proposés dans Firefox. pour les résolveurs DNS dignes de confiance, selon lesquelles l'opérateur DNS ne peut utiliser les données obtenues pour le résolve peut que pour garantir le bon fonctionnement du service, ne doit pas conserver de journaux pendant plus de 24 heures, ne peut transmettre les données à des tiers et doit divulguer des informations sur les méthodes de traitement des données. Le service doit également s'engager à ne pas censurer, filtrer, interférer ou bloquer le trafic DNS, sauf dans les situations prévues par la loi.
Le DoH doit être utilisé avec prudence. Par exemple, en Russie, les adresses IP 104.16.248.249 et 104.16.249.249, associées au serveur DoH proposé par défaut dans Firefox mozilla.cloudflare-dns.com, dans à la demande du tribunal de Stavropol en date du 10.06.2013.
L'utilisation du DoH peut également causer des problèmes dans des domaines tels que les systèmes de contrôle parental, l'accès aux espaces de noms internes dans les systèmes d'entreprise, le choix des routes dans les systèmes d'optimisation de la livraison de contenu et l'exécution des ordonnances judiciaires concernant la lutte contre la diffusion de contenu illégal et l'exploitation des mineurs. Pour contourner de tels problèmes, un système de vérifications a été mis en place et testé, qui désactive automatiquement le DoH dans certaines conditions.
Pour déterminer les résolveurs d'entreprise, des vérifications des domaines de premier niveau atypiques (TLD) sont effectuées et les adresses intranet sont renvoyées 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. Si le résultat ne correspond pas à l'IP réelle, cela signifie qu'un blocage de contenu pour adultes est actif au niveau DNS. Des vérifications des adresses IP de Google et de YouTube sont également effectuées pour voir si elles sont redirigées vers restrict.youtube.com, forcesafesearch.google.com et restrictmoderate.youtube.com. Ces vérifications permettent aux attaquants, qui contrôlent le fonctionnement du résolveur ou peuvent interférer avec le trafic, de simuler un tel comportement pour désactiver le chiffrement du trafic DNS.
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.
Source : opennet.ru
