Chrome 78-s alustatakse DNS-over-HTTPS-i aktiveerimise katsetusi

Jätkates Mozilla ettevõte Google teatas kavatseb läbi viia katsetuse, et kontrollida Chrome'i brauseris arendatava "DNS HTTPS üle" (DoH, DNS over HTTPS) teostust. Chrome'i 78 versioonis, mis on planeeritud 22. oktoobriks, suunatakse teatud kasutajate kategooriad vaikimisi tõlgitud DoH-i kasutamisele. DoH-i aktiveerimise katsetuses osalevad ainult need kasutajad, kelle praegustes süsteemsetes seadetes on määratud teatud DNS-teenusepakkujad, mida peetakse DoH-iga ühilduvaks.

DNS-teenusepakkujate nimekirja on kaasatud teenused 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) ja DNS.SB (185.222.222.222, 185.184.222.222). Kui kasutaja DNS-seadetest on määratud mõni ülaltoodud DNS-server, aktiveeritakse Chrome'is DoH vaikimisi. Need, kes kasutavad kohalikult internetiteenusepakkujalt saadud DNS-servereid, jäävad senisesse olukorda ja DNS-päringute jaoks kasutatakse süsteemi resolvrit.

Oluline erinevus DoH-i juurutamise ja Firefoxi vahel, kus DoH-i vaikimisi järkjärguline aktiveerimine algab juba septembri lõpus, on see, et ei ole seostatud ühekordse DoH-teenusega. Kui Firefoxis on vaikimisi kasutatakse DNS-server CloudFlare, siis Chrome'is värskendatakse DNS-i käsitlemise meetodit ainult ekvivalentse teenuse suunas, ilma DNS-teenusepakkujat vahetamata. Näiteks, kui kasutaja süsteemseadetes on määratud DNS 8.8.8.8, siis Chrome'is lipuke «same-site-by-default-cookies», mis, kui Set-Cookie päises ei ole SameSite atribuuti, seab vaikimisi väärtuseks «SameSite=Lax», piirates küpsiste edastamist kolmandate osapoolte saitidelt (kui saitidel on endiselt võimalik piirangut tühistada, seades küpsiste loomisel selgesõnaliselt atribuudi SameSite=None). kasutatakse Google'i DoH-teenust ("https://dns.google.com/dns-query"), kui DNS on 1.1.1.1, siis DoH-teenus Cloudflare ("https://cloudflare-dns.com/dns-query") ja jne.

Kasutaja saab soovi korral DoH-i aktiveerida või deaktiveerida seades "chrome://flags/#dns-over-https". Toetatakse kolme töörežiimi: "secure", "automatic" ja "off". Režiimis "secure" määratakse hostid ainult varasemate vahemällu salvestatud turvaliste väärtuste (saadud kaitstud ühenduse kaudu) ja DoH-i kaudu tehtud päringute põhjal, tavalise DNS-i juurde tagasiviimist ei rakendata. Režiimis "automatic" kui DoH ja turvaline vahemälu ei ole saadaval, lubatakse andmete saamine mitteturvalisest vahemälust ja pöördumine traditsioonilise DNS-i kaudu. Režiimis "off" kontrollitakse esmalt üldist vahemälu ja kui andmeid ei leita, saadetakse päring süsteemse DNS-i kaudu. Režiim määratakse seadistuse kaudu kDnsOverHttpsMode, ja serverite vastavushallitus läbi kDnsOverHttpsTemplates.

DoH-i aktiveerimise katsetus viiakse läbi kõigis Chrome'i toetavates platvormides, välja arvatud Linux ja iOS, kuna resolveri seadete töötlemine ja süsteemiliste DNS-seadete juurde pääsemine on keeruline. Kui pärast DoH-i aktiveerimist tekib DoH-serveri päringute edastamisel tõrkeid (näiteks serveri blokeerimise, võrguühenduse katkemise või rikete tõttu), naaseb brauser automaatselt süsteemsetesse DNS-seadetesse.

Katsetuse eesmärk on DoH-i teostuse lõplik kontroll ja selle mõju uurimine. Tuleb märkida, et DoH-i tugi on on lisatud Chrome'i koodibaasi sisenenud juba veebruaris, kuid DoH-i seadistamiseks ja aktiveerimiseks oli vajalik Chrome'i käivitamine spetsiifilise lipukesega ja keerulise valiku valikuga.

Meenutame, et DoH võib olla kasulik, et vältida jaotatud DNS-serverite kaudu saadetud teabe lekkeid, võidelda MITM-rünnakute ja DNS-i liikluse valeandmete vastu (näiteks avalike Wi-Fi-võrkude kasutamisel), vastuseid DNS-tasandi blokeeringutele (DoH ei saa asendada VPN-i blokeeringute ületamiseks, mis on rakendatud DPI tasemel) või organiseerida tööd olukordades, kus otsene ligipääs DNS-serveritele ei ole võimalik (nt proxy kaudu töötades). Kui tavalistes oludes saadetakse DNS-päringud otseselt süsteemi DNS-serveritele, siis DoH-i puhul kapseldatakse hosti IP-aadressi määramise päring HTTPS-i liiklusse ja saadetakse HTTP-serverisse, kus resolver töötleb päringud läbi Web API. Olemasolev standard DNSSEC kasutab krüpteerimist ainult kliendi ja serveri autentimiseks, kuid ei kaitse liiklust pealtkuulamise eest ega garanteeri päringute konfidentsiaalsust.

Allikas: opennet.ru