Chrome 78 kommer att börja experimentera med att aktivera DNS-over-HTTPS

Följande Mozilla Google-företag rapporterad om avsikten att genomföra ett experiment för att testa implementeringen "DNS över HTTPS" (DoH, DNS över HTTPS) som utvecklas för webbläsaren Chrome. Chrome 78, planerad till den 22 oktober, kommer att ha vissa användarkategorier som standard översatt att använda DoH. Endast användare vars nuvarande systeminställningar anger vissa DNS-leverantörer som känns igen som kompatibla med DoH kommer att delta i experimentet för att aktivera DoH.

Den vita listan över DNS-leverantörer inkluderar tjänster 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), renbrowing (185.228.168.168. 185.228.169.168, 185.222.222.222) och DNS.SB (185.184.222.222, XNUMX). Om användarens DNS-inställningar anger en av de ovan nämnda DNS-servrarna, kommer DoH i Chrome att vara aktiverat som standard. För de som använder DNS-servrar som tillhandahålls av sin lokala internetleverantör kommer allt att förbli oförändrat och systemlösaren kommer att fortsätta att användas för DNS-frågor.

En viktig skillnad från implementeringen av DoH i Firefox, som gradvis aktiverade DoH som standard Ska börja redan i slutet av september, är avsaknaden av bindning till en DoH-tjänst. Om i Firefox som standard används CloudFlare DNS-server, då kommer Chrome bara att uppdatera metoden för att arbeta med DNS till en likvärdig tjänst, utan att byta DNS-leverantör. Till exempel, om användaren har DNS 8.8.8.8 specificerat i systeminställningarna, kommer Chrome att göra det aktiveras Google DoH-tjänst (“https://dns.google.com/dns-query”), om DNS är 1.1.1.1, då Cloudflare DoH-tjänst (“https://cloudflare-dns.com/dns-query”) Och etc.

Om så önskas kan användaren aktivera eller inaktivera DoH med inställningen "chrome://flags/#dns-over-https". Tre driftslägen stöds: säker, automatisk och avstängd. I "säkert" läge bestäms värdar endast baserat på tidigare cachade säkra värden (mottagna via en säker anslutning) och förfrågningar via DoH; reserv till vanlig DNS tillämpas inte. I det "automatiska" läget, om DoH och den säkra cachen inte är tillgängliga, kan data hämtas från den osäkra cachen och nås via traditionell DNS. I "av"-läge kontrolleras först den delade cachen och om det inte finns några data skickas begäran via systemets DNS. Läget ställs in via anpassning kDnsOverHttpsMode och servermappningsmallen genom kDnsOverHttpsTemplates.

Experimentet för att aktivera DoH kommer att utföras på alla plattformar som stöds i Chrome, med undantag för Linux och iOS på grund av den icke-triviala karaktären av att analysera resolverinställningar och begränsa åtkomsten till systemets DNS-inställningar. Om det, efter att ha aktiverat DoH, det finns problem med att skicka förfrågningar till DoH-servern (till exempel på grund av dess blockering, nätverksanslutning eller fel), kommer webbläsaren automatiskt att returnera systemets DNS-inställningar.

Syftet med experimentet är att sluttesta implementeringen av DoH och studera effekten av att använda DoH på prestanda. Det bör noteras att DoH-stöd faktiskt var Lagt till i Chrome-kodbasen redan i februari, men för att konfigurera och aktivera DoH nödvändig lanserar Chrome med en speciell flagga och en icke-uppenbar uppsättning alternativ.

Låt oss komma ihåg att DoH kan vara användbart för att förhindra läckor av information om de begärda värdnamnen genom leverantörernas DNS-servrar, bekämpa MITM-attacker och DNS-trafikförfalskning (till exempel vid anslutning till offentligt Wi-Fi), motverka blockering på DNS nivå (DoH kan inte ersätta en VPN inom området för att kringgå blockering implementerad på DPI-nivå) eller för att organisera arbete om det är omöjligt att direkt komma åt DNS-servrar (till exempel när du arbetar via en proxy). Om DNS-förfrågningar i en normal situation skickas direkt till DNS-servrar definierade i systemkonfigurationen, då i fallet med DoH, är begäran om att fastställa värdens IP-adress inkapslad i HTTPS-trafik och skickas till HTTP-servern, där resolvern bearbetar förfrågningar via webb-API. Den befintliga DNSSEC-standarden använder endast kryptering för att autentisera klienten och servern, men skyddar inte trafik från avlyssning och garanterar inte konfidentialitet för förfrågningar.

Källa: opennet.ru

Lägg en kommentar