DNS sur HTTPS est activé par défaut dans Firefox pour les utilisateurs américains

Développeurs Firefox annoncé sur l'activation du mode DNS sur HTTPS (DoH, DNS sur HTTPS) par défaut pour les utilisateurs américains. Le cryptage du trafic DNS est considéré comme un facteur fondamental pour la protection des utilisateurs. À partir d’aujourd’hui, DoH sera activé par défaut pour toutes les nouvelles installations réalisées par des utilisateurs américains. Les utilisateurs américains existants devraient passer au DoH d’ici quelques semaines. Dans l'Union européenne et dans d'autres pays, activez DoH par défaut pour l'instant ne planifie pas.

Après avoir activé DoH, un avertissement s'affiche à l'utilisateur, qui permet, s'il le souhaite, de refuser de contacter les serveurs DNS centralisés de DoH et de revenir au schéma traditionnel d'envoi de requêtes non cryptées au serveur DNS du fournisseur. Au lieu d'une infrastructure distribuée de résolveurs DNS, DoH utilise une liaison à un service DoH spécifique, qui peut être considéré comme un point de défaillance unique. Actuellement, le travail est proposé via deux fournisseurs DNS : CloudFlare (par défaut) et NextDNS.

DNS sur HTTPS est activé par défaut dans Firefox pour les utilisateurs américains

Changer de fournisseur ou désactiver DoH on peut dans les paramètres de connexion réseau. Par exemple, vous pouvez spécifier un autre serveur DoH « https://dns.google/dns-query » pour accéder aux serveurs Google, « https://dns.quad9.net/dns-query » - Quad9 et « https:/ /doh.opendns.com/dns-query" - OpenDNS. About:config fournit également le paramètre network.trr.mode, grâce auquel vous pouvez modifier le mode de fonctionnement de DoH : une valeur de 0 désactive complètement DoH ; 1 - DNS ou DoH est utilisé, selon celui qui est le plus rapide ; 2 - DoH est utilisé par défaut et DNS est utilisé comme option de secours ; 3 - seul DoH est utilisé ; 4 - mode miroir dans lequel DoH et DNS sont utilisés en parallèle.

Rappelons que DoH peut être utile pour empêcher les fuites d'informations sur les noms d'hôtes demandés via les serveurs DNS des fournisseurs, lutter contre les attaques MITM et l'usurpation du trafic DNS (par exemple, lors de la connexion au Wi-Fi public), contrer le blocage au niveau du DNS. (Le DoH ne peut pas remplacer un VPN dans le domaine du contournement des blocages mis en œuvre au niveau DPI) ou pour organiser le travail s'il est impossible d'accéder directement aux serveurs DNS (par exemple, lorsque l'on travaille via un proxy). Si dans une situation normale les requêtes DNS sont directement envoyées aux serveurs DNS définis dans la configuration du 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 au serveur HTTP, où le résolveur traite requêtes via l’API Web. La norme DNSSEC existante 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 demandes.

Pour sélectionner les fournisseurs DoH proposés dans Firefox, exigences à des résolveurs DNS fiables, selon lesquels l'opérateur DNS peut utiliser les données reçues à des fins de résolution uniquement pour assurer le fonctionnement du service, ne doit pas stocker de journaux pendant plus de 24 heures, ne peut pas transférer de données à des tiers et est obligé de divulguer des informations sur 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.

DoH doit être utilisé avec prudence. Par exemple, en Fédération de Russie, les adresses IP 104.16.248.249 et 104.16.249.249 associées au serveur DoH par défaut mozilla.cloudflare-dns.com proposé dans Firefox, listé в des listes blocage Roskomnadzor à la demande du tribunal de Stavropol en date du 10.06.2013 juin XNUMX.

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, la sélection d'itinéraires dans les systèmes d'optimisation de la diffusion de contenu et le respect des ordonnances des tribunaux dans le domaine de la lutte contre la distribution de contenus illégaux et l'exploitation de mineurs. Pour contourner de tels problèmes, un système de contrôle a été mis en œuvre et testé qui désactive automatiquement DoH dans certaines conditions.

Pour identifier les résolveurs d'entreprise, les domaines de premier niveau (TLD) atypiques sont vérifiés et le résolveur système renvoie les adresses intranet. Pour déterminer si le contrôle parental est activé, une tentative est faite pour résoudre le nom exampleadultsite.com et si le résultat ne correspond pas à l'adresse IP réelle, on considère que le blocage du contenu pour adultes est actif au niveau DNS. Les adresses IP de Google et YouTube sont également vérifiées en tant que signes pour voir si elles ont été remplacées par 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 sont capables d'interférer avec le trafic de simuler un tel comportement pour désactiver le cryptage du trafic DNS.

Travailler via un seul service DoH peut également potentiellement entraîner des problèmes d'optimisation du trafic dans les réseaux de diffusion de contenu qui équilibrent le trafic à l'aide du DNS (le serveur DNS du réseau CDN génère une réponse en tenant compte de l'adresse du résolveur et fournit l'hôte le plus proche pour recevoir le contenu). L'envoi d'une requête DNS depuis le résolveur le plus proche de l'utilisateur dans de tels CDN renvoie l'adresse de l'hôte le plus proche de l'utilisateur, mais l'envoi d'une requête DNS depuis un résolveur centralisé renverra l'adresse de l'hôte la plus proche du serveur DNS sur HTTPS. . Les tests pratiques ont montré que l'utilisation du DNS sur HTTP lors de l'utilisation d'un CDN n'entraînait pratiquement aucun délai avant le début du transfert de contenu (pour les connexions rapides, les délais ne dépassaient pas 10 millisecondes, et des performances encore plus rapides étaient observées sur les canaux de communication lents. ). L’utilisation de l’extension EDNS Client Subnet a également été envisagée pour fournir des informations sur l’emplacement du client au résolveur CDN.

Source: opennet.ru

Ajouter un commentaire