DNS-over-HTTPS està habilitat de manera predeterminada a Firefox per als usuaris dels EUA

Desenvolupadors de Firefox va anunciar sobre l'habilitació del mode DNS sobre HTTPS (DoH, DNS sobre HTTPS) de manera predeterminada per als usuaris dels EUA. El xifratge del trànsit DNS es considera un factor fonamentalment important per protegir els usuaris. A partir d'avui, totes les instal·lacions noves dels usuaris dels EUA tindran DoH habilitat de manera predeterminada. Està previst que els usuaris actuals dels Estats Units canviïn a DoH en unes poques setmanes. A la Unió Europea i altres països, activeu DoH de manera predeterminada de moment no planifiqueu.

Després d'activar DoH, es mostra a l'usuari un avís que permet, si ho desitja, negar-se a contactar amb servidors DNS DoH centralitzats i tornar a l'esquema tradicional d'enviament de consultes sense xifrar al servidor DNS del proveïdor. En lloc d'una infraestructura distribuïda de resolutors DNS, DoH utilitza una vinculació a un servei DoH específic, que es pot considerar un únic punt de fallada. Actualment, el treball s'ofereix a través de dos proveïdors de DNS: CloudFlare (per defecte) i NextDNS.

DNS-over-HTTPS està habilitat de manera predeterminada a Firefox per als usuaris dels EUA

Canvia de proveïdor o desactiva DoH un pot a la configuració de connexió de xarxa. Per exemple, podeu especificar un servidor DoH alternatiu "https://dns.google/dns-query" per accedir als servidors de Google, "https://dns.quad9.net/dns-query" - Quad9 i "https:/ /doh .opendns.com/dns-query" - OpenDNS. About:config també proporciona la configuració network.trr.mode, mitjançant la qual podeu canviar el mode de funcionament DoH: un valor de 0 desactiva completament DoH; 1 - S'utilitza DNS o DoH, el que sigui més ràpid; 2 - DoH s'utilitza per defecte i DNS s'utilitza com a opció alternativa; 3 - només s'utilitza DoH; 4 - Mode de duplicació en què DoH i DNS s'utilitzen en paral·lel.

Recordem que DoH pot ser útil per prevenir filtracions d'informació sobre els noms d'amfitrió sol·licitats a través dels servidors DNS dels proveïdors, combatre els atacs MITM i la falsificació del trànsit DNS (per exemple, quan es connecta a una xarxa Wi-Fi pública), contrarestar el bloqueig al DNS. nivell (DoH no pot substituir una VPN a l'àrea d'obviació del bloqueig implementat a nivell de DPI) o per organitzar el treball si és impossible accedir directament als servidors DNS (per exemple, quan es treballa a través d'un proxy). Si en una situació normal les sol·licituds DNS s'envien directament als servidors DNS definits a la configuració del sistema, aleshores, en el cas de DoH, la sol·licitud per determinar l'adreça IP de l'amfitrió s'encapsula en el trànsit HTTPS i s'envia al servidor HTTP, on el resolutor processa sol·licituds mitjançant l'API web. L'estàndard DNSSEC existent només utilitza el xifratge per autenticar el client i el servidor, però no protegeix el trànsit de la intercepció i no garanteix la confidencialitat de les sol·licituds.

Per seleccionar els proveïdors de DoH que s'ofereixen a Firefox, exigeix a solucionadors de DNS de confiança, segons els quals l'operador de DNS pot utilitzar les dades rebudes per a la resolució només per garantir el funcionament del servei, no ha d'emmagatzemar registres durant més de 24 hores, no pot transferir dades a tercers i està obligat a revelar informació sobre mètodes de tractament de dades. El servei també ha d'acceptar no censurar, filtrar, interferir o bloquejar el trànsit DNS, excepte en les situacions previstes per la llei.

DoH s'ha d'utilitzar amb precaució. Per exemple, a la Federació Russa, les adreces IP 104.16.248.249 i 104.16.249.249 associades amb el servidor DoH predeterminat mozilla.cloudflare-dns.com que s'ofereix a Firefox, enumerat в les llistes bloqueig Roskomnadzor a petició del tribunal de Stavropol de data 10.06.2013 de juny de XNUMX.

El DoH també pot causar problemes en àrees com els sistemes de control parental, l'accés a espais de noms interns en sistemes corporatius, la selecció de rutes en sistemes d'optimització de lliurament de continguts i el compliment de les ordres judicials en l'àmbit de la lluita contra la distribució de contingut il·legal i l'explotació de continguts. menors d'edat. Per evitar aquests problemes, s'ha implementat i provat un sistema de verificació que desactiva automàticament DoH en determinades condicions.

Per identificar els solucionadors empresarials, es comproven els dominis de primer nivell (TLD) atípics i el resolutor del sistema retorna adreces d'intranet. Per determinar si els controls parentals estan activats, s'intenta resoldre el nom exampleadultsite.com i si el resultat no coincideix amb la IP real, es considera que el bloqueig de contingut per a adults està actiu a nivell de DNS. Les adreces IP de Google i YouTube també es comproven com a senyals per veure si han estat substituïdes per restrict.youtube.com, forcesafesearch.google.com i restrictmoderate.youtube.com. Aquestes comprovacions permeten als atacants que controlen el funcionament del resolutor o que són capaços d'interferir amb el trànsit simular aquest comportament per desactivar l'encriptació del trànsit DNS.

Treballar a través d'un únic servei DoH també pot provocar problemes amb l'optimització del trànsit a les xarxes de lliurament de contingut que fan un equilibri de trànsit mitjançant DNS (el servidor DNS de la xarxa CDN genera una resposta, tenint en compte l'adreça del resolutor i emet l'amfitrió més proper). rebre contingut). L'enviament d'una consulta DNS des del solucionador més proper a l'usuari en aquests CDN retorna l'adreça de l'amfitrió més propera a l'usuari, però l'enviament d'una consulta DNS des del resolutor centralitzat retornarà l'adreça de l'amfitrió més propera al servidor DNS-over-HTTPS. Les proves a la pràctica van demostrar que l'ús de DNS-over-HTTP quan s'utilitzava un CDN pràcticament no va provocar retards abans de l'inici de la transferència de contingut (per a connexions ràpides, els retards no van superar els 10 mil·lisegons i fins i tot es va observar una acceleració en canals de comunicació lents). ). També vam considerar utilitzar l'extensió de subxarxa de client EDNS per passar la informació d'ubicació del client al solucionador de CDN.

Font: opennet.ru

Afegeix comentari