Seguint empresa de Google sobre la intenció de dur a terme un experiment per provar la implementació "DNS sobre HTTPS" (DoH, DNS sobre HTTPS) que s'està desenvolupant per al navegador Chrome. Chrome 78, previst per al 22 d'octubre, tindrà algunes categories d'usuari de manera predeterminada per utilitzar DoH. Només els usuaris la configuració actual del sistema dels quals especifiquen determinats proveïdors de DNS reconeguts com a compatibles amb DoH participaran en l'experiment per habilitar DoH.
La llista blanca de proveïdors de DNS inclou Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), 185.228.168.168, 185.228.169.168) i DNS.SB (185.222.222.222, 185.184.222.222). Si la configuració del DNS de l'usuari especifica un dels servidors DNS esmentats anteriorment, DoH a Chrome s'habilitarà de manera predeterminada. Per a aquells que utilitzen servidors DNS proporcionats pel seu proveïdor d'Internet local, tot es mantindrà sense canvis i la resolució del sistema es continuarà utilitzant per a consultes DNS.
Una diferència important amb la implementació de DoH a Firefox, que gradualment va habilitar DoH per defecte ja a finals de setembre, és la manca de vinculació a un servei DoH. Si està al Firefox per defecte Servidor DNS de CloudFlare, Chrome només actualitzarà el mètode de treball amb DNS a un servei equivalent, sense canviar el proveïdor de DNS. Per exemple, si l'usuari té el DNS 8.8.8.8 especificat a la configuració del sistema, Chrome ho farà Servei DoH de Google ("https://dns.google.com/dns-query"), si el DNS és 1.1.1.1, llavors el servei DoH de Cloudflare ("https://cloudflare-dns.com/dns-query") i
Si ho desitja, l'usuari pot activar o desactivar DoH mitjançant la configuració "chrome://flags/#dns-over-https". S'admeten tres modes de funcionament: segur, automàtic i apagat. En el mode "segur", els amfitrions es determinen només en funció dels valors segurs guardats a la memòria cau prèviament (rebuts mitjançant una connexió segura) i de les sol·licituds mitjançant DoH; no s'aplica el recurs al DNS normal. En el mode "automàtic", si DoH i la memòria cau segura no estan disponibles, les dades es poden recuperar de la memòria cau insegura i accedir-hi mitjançant el DNS tradicional. En mode "desactivat", primer es comprova la memòria cau compartida i si no hi ha dades, la sol·licitud s'envia a través del DNS del sistema. El mode s'estableix mitjançant kDnsOverHttpsMode i la plantilla de mapatge del servidor mitjançant kDnsOverHttpsTemplates.
L'experiment per habilitar DoH es portarà a terme a totes les plataformes compatibles amb Chrome, a excepció de Linux i iOS a causa de la naturalesa no trivial de l'anàlisi de la configuració del resolutor i la restricció de l'accés a la configuració del DNS del sistema. Si, després d'habilitar DoH, hi ha problemes per enviar sol·licituds al servidor DoH (per exemple, a causa del seu bloqueig, connectivitat de xarxa o fallada), el navegador retornarà automàticament la configuració del DNS del sistema.
L'objectiu de l'experiment és provar finalment la implementació de DoH i estudiar l'impacte de l'ús de DoH en el rendiment. Cal assenyalar que, de fet, el suport de DoH ho era al codi base de Chrome el febrer, però per configurar i habilitar DoH llançant Chrome amb una bandera especial i un conjunt d'opcions no evident.
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 utilitza el xifratge només 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.
Font: opennet.ru