Chrome 78 begynder at eksperimentere med at aktivere DNS-over-HTTPS

Følge Mozilla Google virksomhed rapporteret om intentionen om at gennemføre et eksperiment for at teste implementeringen "DNS over HTTPS" (DoH, DNS over HTTPS), der udvikles til Chrome-browseren. Chrome 78, der er planlagt til den 22. oktober, vil som standard have nogle brugerkategorier oversat at bruge DoH. Kun brugere, hvis nuværende systemindstillinger angiver visse DNS-udbydere, der er anerkendt som kompatible med DoH, vil deltage i eksperimentet for at aktivere DoH.

Den hvide liste over DNS-udbydere inkluderer tjenester 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), CleanBrowsing (185.228.168.168. 185.228.169.168, 185.222.222.222) og DNS.SB (185.184.222.222, XNUMX). Hvis brugerens DNS-indstillinger angiver en af ​​de ovennævnte DNS-servere, vil DoH i Chrome være aktiveret som standard. For dem, der bruger DNS-servere leveret af deres lokale internetudbyder, vil alt forblive uændret, og systemopløsningen vil fortsat blive brugt til DNS-forespørgsler.

En vigtig forskel fra implementeringen af ​​DoH i Firefox, som gradvist aktiverede DoH som standard vil begynde allerede i slutningen af ​​september, er manglen på binding til én DoH-tjeneste. Hvis i Firefox som standard brugt CloudFlare DNS-server, så opdaterer Chrome kun metoden til at arbejde med DNS til en tilsvarende tjeneste uden at ændre DNS-udbyderen. For eksempel, hvis brugeren har DNS 8.8.8.8 angivet i systemindstillingerne, så vil Chrome aktiveret Google DoH-tjeneste ("https://dns.google.com/dns-query"), hvis DNS er 1.1.1.1, så Cloudflare DoH-tjeneste ("https://cloudflare-dns.com/dns-query") og etc.

Hvis det ønskes, kan brugeren aktivere eller deaktivere DoH ved at bruge indstillingen "chrome://flags/#dns-over-https". Tre driftstilstande understøttes: sikker, automatisk og slukket. I "sikker" tilstand bestemmes værter kun baseret på tidligere cachelagrede sikre værdier (modtaget via en sikker forbindelse) og anmodninger via DoH; fallback til almindelig DNS anvendes ikke. I den "automatiske" tilstand, hvis DoH og den sikre cache ikke er tilgængelig, kan data hentes fra den usikre cache og tilgås via traditionel DNS. I "fra"-tilstand kontrolleres den delte cache først, og hvis der ikke er nogen data, sendes anmodningen gennem systemets DNS. Tilstanden indstilles via tilpasning kDnsOverHttpsMode og servertilknytningsskabelonen gennem kDnsOverHttpsTemplates.

Eksperimentet for at aktivere DoH vil blive udført på alle platforme, der understøttes i Chrome, med undtagelse af Linux og iOS på grund af den ikke-trivielle karakter af parsing af resolver-indstillinger og begrænsning af adgang til systemets DNS-indstillinger. Hvis der efter aktivering af DoH er problemer med at sende anmodninger til DoH-serveren (f.eks. på grund af blokering, netværksforbindelse eller fejl), vil browseren automatisk returnere systemets DNS-indstillinger.

Formålet med eksperimentet er at endelig teste implementeringen af ​​DoH og undersøge virkningen af ​​at bruge DoH på ydeevnen. Det skal bemærkes, at DoH-støtte faktisk var tilføjet ind i Chrome-kodebasen tilbage i februar, men for at konfigurere og aktivere DoH påkrævet lancering af Chrome med et særligt flag og et ikke-oplagt sæt muligheder.

Lad os huske på, at DoH kan være nyttigt til at forhindre læk af information om de anmodede værtsnavne gennem udbydernes DNS-servere, bekæmpe MITM-angreb og DNS-trafik-spoofing (for eksempel ved tilslutning til offentlig Wi-Fi), modvirke blokering på DNS. niveau (DoH kan ikke erstatte en VPN i området for omgåelse af blokering implementeret på DPI-niveau) eller til at organisere arbejde, hvis det er umuligt at få direkte adgang til DNS-servere (f.eks. når du arbejder gennem en proxy). Hvis DNS-anmodninger i en normal situation sendes direkte til DNS-servere defineret i systemkonfigurationen, så i tilfælde af DoH, indkapsles anmodningen om at bestemme værtens IP-adresse i HTTPS-trafik og sendes til HTTP-serveren, hvor resolveren behandler anmodninger via Web API. Den eksisterende DNSSEC-standard bruger kun kryptering til at autentificere klienten og serveren, men beskytter ikke trafik mod aflytning og garanterer ikke fortroligheden af ​​anmodninger.

Kilde: opennet.ru

Tilføj en kommentar