Chrome 78 sāks eksperimentēt, iespējojot DNS, izmantojot HTTPS

Sekojošs Mozilla Google uzņēmums ziņots par nodomu veikt eksperimentu, lai pārbaudītu “DNS, izmantojot HTTPS” (DoH, DNS, izmantojot HTTPS) implementāciju, kas tiek izstrādāta pārlūkam Chrome. Pārlūkā Chrome 78, kas paredzēts 22. oktobrī, pēc noklusējuma būs dažas lietotāju kategorijas tulkots izmantot DoH. Eksperimentā, lai iespējotu DoH, piedalīsies tikai tie lietotāji, kuru pašreizējie sistēmas iestatījumi norāda noteiktus DNS pakalpojumu sniedzējus, kas atzīti par saderīgiem ar DoH.

DNS nodrošinātāju baltajā sarakstā ietilpst pakalpojumi 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) un DNS.SB (185.222.222.222, 185.184.222.222). Ja lietotāja DNS iestatījumos ir norādīts kāds no iepriekš minētajiem DNS serveriem, DoH pārlūkā Chrome tiks aktivizēts pēc noklusējuma. Tiem, kas izmanto sava vietējā interneta nodrošinātāja nodrošinātos DNS serverus, viss paliks nemainīgs un DNS vaicājumiem turpinās izmantot sistēmas atrisinātāju.

Būtiska atšķirība no DoH ieviešanas pārlūkprogrammā Firefox, kas pēc noklusējuma pakāpeniski iespējoja DoH sāksies jau septembra beigās nav saistoša vienam DoH dienestam. Ja pārlūkprogrammā Firefox pēc noklusējuma lietots CloudFlare DNS serveri, tad Chrome atjauninās tikai metodi darbam ar DNS uz līdzvērtīgu pakalpojumu, nemainot DNS nodrošinātāju. Piemēram, ja lietotājam sistēmas iestatījumos ir norādīts DNS 8.8.8.8, Chrome to darīs aktivizēts Google DoH pakalpojums (“https://dns.google.com/dns-query”), ja DNS ir 1.1.1.1, tad pakalpojums Cloudflare DoH (“https://cloudflare-dns.com/dns-query”) un utt.

Ja vēlas, lietotājs var iespējot vai atspējot DoH, izmantojot iestatījumu “chrome://flags/#dns-over-https”. Tiek atbalstīti trīs darbības režīmi: drošs, automātisks un izslēgts. “Drošajā” režīmā saimniekdatori tiek noteikti, tikai pamatojoties uz iepriekš kešatmiņā saglabātajām drošajām vērtībām (saņemtas, izmantojot drošu savienojumu) un pieprasījumiem, izmantojot DoH; atkāpšanās uz parasto DNS netiek piemērota. “Automātiskajā” režīmā, ja DoH un drošā kešatmiņa nav pieejami, datus var izgūt no nedrošās kešatmiņas un tiem piekļūt, izmantojot tradicionālo DNS. “Izslēgtā” režīmā vispirms tiek pārbaudīta koplietotā kešatmiņa un, ja datu nav, pieprasījums tiek nosūtīts caur sistēmas DNS. Režīms ir iestatīts, izmantojot pielāgošana kDnsOverHttpsMode un servera kartēšanas veidni, izmantojot kDnsOverHttpsTemplates.

Eksperiments, lai iespējotu DoH, tiks veikts visās Chrome atbalstītajās platformās, izņemot Linux un iOS, jo atrisinātāja iestatījumu parsēšana un piekļuves ierobežošana sistēmas DNS iestatījumiem nav triviāla. Ja pēc DoH iespējošanas rodas problēmas ar pieprasījumu nosūtīšanu uz DoH serveri (piemēram, tā bloķēšanas, tīkla savienojuma vai kļūmes dēļ), pārlūkprogramma automātiski atgriezīs sistēmas DNS iestatījumus.

Eksperimenta mērķis ir galīgi pārbaudīt DoH ieviešanu un izpētīt DoH izmantošanas ietekmi uz veiktspēju. Jāpiebilst, ka patiesībā DoH atbalsts bija pievienots Chrome kodu bāzē jau februārī, bet lai konfigurētu un iespējotu DoH nepieciešams Chrome palaišana ar īpašu karogu un nepārprotamu opciju kopumu.

Atgādināsim, ka DoH var būt noderīga, lai novērstu informācijas noplūdi par pieprasītajiem resursdatora nosaukumiem caur pakalpojumu sniedzēju DNS serveriem, apkarotu MITM uzbrukumus un DNS trafika viltošanu (piemēram, pieslēdzoties publiskajam Wi-Fi), apkarotu bloķēšanu DNS. līmenī (DoH nevar aizstāt VPN DPI līmenī ieviestās bloķēšanas apiešanas jomā) vai darba organizēšanai, ja nav iespējams tieši piekļūt DNS serveriem (piemēram, strādājot caur starpniekserveri). Ja normālā situācijā DNS pieprasījumi tiek tieši nosūtīti uz sistēmas konfigurācijā definētajiem DNS serveriem, tad DoH gadījumā pieprasījums noteikt saimniekdatora IP adresi tiek iekapsulēts HTTPS trafikā un nosūtīts uz HTTP serveri, kur atrisinātājs apstrādā. pieprasījumus, izmantojot Web API. Esošais DNSSEC standarts izmanto šifrēšanu tikai klienta un servera autentifikācijai, taču neaizsargā trafiku no pārtveršanas un negarantē pieprasījumu konfidencialitāti.

Avots: opennet.ru

Pievieno komentāru