Chrome 78 DNS-gaineko HTTPS gaitzen esperimentatzen hasiko da

Jarraian Mozilla Google konpainia jakinarazi du Chrome arakatzailerako garatzen ari den "DNS over HTTPS" (DoH, DNS over HTTPS) ezarpena probatzeko esperimentu bat egiteko asmoari buruz. Urriaren 78rako aurreikusita dagoen Chrome 22-k erabiltzaile-kategoria batzuk izango ditu lehenespenez itzulia DoH erabiltzeko. DoH-rekin bateragarriak diren DNS hornitzaile jakin batzuk zehazten dituzten sistemaren uneko ezarpenek soilik hartuko dute parte DoH gaitzeko esperimentuan.

DNS hornitzaileen zerrenda zuriak barne hartzen ditu Zerbitzuak Google-k (8.8.8.8), CloudFlare (8.8.4.4, 1.1.1.1), OpenDNS (1.0.0.1, 208.67.222.222), Quad208.67.220.220 (9, 9.9.9.9) (149.112.112.112 185.228.168.168) , 185.228.169.168) eta DNS.SB (185.222.222.222, 185.184.222.222). Erabiltzailearen DNS ezarpenak goian aipatutako DNS zerbitzarietako bat zehazten badu, DoH Chrome-n gaituta egongo da lehenespenez. Beren tokiko Interneteko hornitzaileak emandako DNS zerbitzariak erabiltzen dituztenentzat, dena aldatu gabe geratuko da eta sistemaren ebazpena DNS kontsultak egiteko erabiltzen jarraituko du.

Desberdintasun garrantzitsu bat DoH Firefox-en inplementatzean, pixkanaka DoH lehenespenez gaitu zuena hasiko da dagoeneko irailaren amaieran, DoH zerbitzu bakarrarekin lotze eza da. Firefox-en bada lehenespenez Erabilitako CloudFlare DNS zerbitzaria, orduan Chrome-k DNSarekin lan egiteko metodoa zerbitzu baliokide batera eguneratuko du soilik, DNS hornitzailea aldatu gabe. Adibidez, erabiltzaileak sistemaren ezarpenetan DNS 8.8.8.8 zehaztuta badu, Chrome-k egingo du aktibatuta Google DoH zerbitzua ("https://dns.google.com/dns-query"), DNS 1.1.1.1 bada, orduan Cloudflare DoH zerbitzua ("https://cloudflare-dns.com/dns-query") Eta etab.

Nahi izanez gero, erabiltzaileak DoH gaitu edo desgaitu dezake "chrome://flags/#dns-over-https" ezarpena erabiliz. Hiru funtzionamendu modu onartzen dira: segurua, automatikoa eta itzalita. Modu "seguruan", ostalariak aldez aurretik cachean gordetako balio seguruetan (konexio seguru baten bidez jasotakoak) eta DoH bidezko eskaeren arabera soilik zehazten dira; ez da DNS arruntaren ordezkapena aplikatzen. "Automatiko" moduan, DoH eta cache segurua erabilgarri ez badaude, datuak cache segurutik berreskura daitezke eta DNS tradizionalen bidez atzitu. "Desaktibatuta" moduan, partekatutako cachea egiaztatzen da lehenik eta daturik ez badago, eskaera sistemako DNS bidez bidaltzen da. Moduaren bidez ezartzen da pertsonalizazioa kDnsOverHttpsMode eta zerbitzariaren mapak egiteko txantiloia kDnsOverHttpsTemplates bidez.

DoH gaitzeko esperimentua Chrome-n onartzen diren plataforma guztietan egingo da, Linux eta iOS izan ezik, soluzio-ezarpenak analizatzearen eta sistemaren DNS ezarpenetarako sarbidea mugatzearen izaera ez hutsala delako. DoH gaitu ondoren, DoH zerbitzariari eskaerak bidaltzeko arazoak badira (adibidez, blokeoagatik, sare-konektibitateagatik edo hutsegiteagatik), arakatzaileak automatikoki itzuliko ditu sistemaren DNS ezarpenak.

Esperimentuaren helburua DoHren inplementazioa probatzea eta DoH erabiltzeak errendimenduan duen eragina aztertzea da. Kontuan izan behar da, hain zuzen ere, DoH laguntza izan zela gehitu Chrome kode-basean sartu otsailean, baina DoH konfiguratu eta gaitzeko beharrezkoak Chrome bandera berezi batekin eta ageriko ez den aukera multzo batekin abiaraziz.

Gogora dezagun DoH hornitzaileen DNS zerbitzarien bidez eskatutako ostalari-izenei buruzko informazio-ihesak saihesteko baliagarria izan daitekeela, MITM erasoei eta DNS trafikoaren faltsioari aurre egiteko (adibidez, Wi-Fi publikora konektatzean), DNSn blokeatzeari aurre egiteko. maila (DoH-k ezin du ordezkatu VPN bat DPI mailan inplementatutako blokeoa saihesteko eremuan) edo lana antolatzeko DNS zerbitzarietara zuzenean sartzea ezinezkoa bada (adibidez, proxy baten bidez lan egiten denean). Egoera normal batean DNS eskaerak sistemaren konfigurazioan definitutako DNS zerbitzarietara zuzenean bidaltzen badira, DoH-ren kasuan, ostalariaren IP helbidea zehazteko eskaera HTTPS trafikoan kapsulatzen da eta HTTP zerbitzarira bidaltzen da, non konpontzaileak prozesatzen duen. eskaerak Web APIaren bidez. Lehendik dagoen DNSSEC estandarrak enkriptatzea erabiltzen du bezeroa eta zerbitzaria autentifikatzeko soilik, baina ez du trafikoa atzematetik babesten eta ez du eskaeren konfidentzialtasuna bermatzen.

Iturria: opennet.ru

Gehitu iruzkin berria