Следам за кампанія Google аб намеры правесці эксперымент для праверкі развіваецца для браўзэра Chrome рэалізацыі "DNS па-над HTTPS" (DoH, DNS over HTTPS). У выпуску Chrome 78, прызначаным на 22 кастрычніка, некаторыя катэгорыі карыстачоў будуць па змаўчанні на выкарыстанне DoH. У эксперыменце па ўключэнні DoH прымуць удзел толькі карыстальнікі, у бягучых сістэмных настойках якіх указаны пэўныя DNS-правайдэры, прызнаныя сумяшчальнымі з DoH.
У белы спіс DNS-правайдэраў уключаны 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) і DNS.SB (185.222.222.222, 185.184.222.222). Калі ў настойках DNS у карыстача будзе паказаны адзін з вышэйзгаданых DNS-сервераў, DoH у Chrome будзе актываваны па змаўчанні. Для тых, хто выкарыстоўвае прадстаўленыя лакальным інтэрнэт-правайдэрам DNS-серверы ўсё застанецца без змен і для запытаў DNS працягне выкарыстоўвацца сістэмны рэзалвер.
Важным адрозненнем ад укаранення DoH у Firefox, у якім паэтапнае ўключэнне па змаўчанні DoH ужо ў канцы верасня, з'яўляецца адсутнасць прывязкі да аднаго сэрвісу DoH. Калі ў Firefox па змаўчанні DNS-сервер CloudFlare, то ў Chrome будзе толькі праведзена абнаўленне метаду працы з DNS на эквівалентны сэрвіс, без змены DNS-правайдэра. Напрыклад, калі ў карыстача ў сістэмных наладах паказаны DNS 8.8.8.8, то ў Chrome будзе DoH-сэрвіс Google ("https://dns.google.com/dns-query"), калі DNS - 1.1.1.1, то DoH сэрвіс Cloudflare ("https://cloudflare-dns.com/dns-query") і
Пры жаданні карыстач зможа ўключыць або адключыць DoH пры дапамозе налады "chrome://flags/#dns-over-https". Падтрымліваецца тры рэжыму працы "secure", "automatic" і "off". У рэжыме «secure» хасты вызначаюцца толькі на аснове раней пракэшаваных бяспечных значэнняў (атрыманых праз абароненае злучэнне) і запытаў праз DoH, адкат на звычайны DNS не прымяняецца. У рэжыме "automatic" калі DoH і абаронены кэш недаступныя дапушчаецца атрыманне дадзеных з небяспечнага кэша і зварот праз традыцыйны DNS. У рэжыме "off" спачатку правяраецца агульны кэш і калі дадзеных няма, запыт адпраўляецца праз сістэмны DNS. Рэжым задаецца праз kDnsOverHttpsMode , а шаблон супастаўлення сервераў праз kDnsOverHttpsTemplates.
Эксперымент па ўключэнні DoH будзе праведзены на ўсіх падтрымліваемых у Chrome платформах, за выключэннем Linux і iOS з-за нетрывіяльнасці разбору налад рэзаверу і абмежаванні доступу да сістэмных налад DNS. У выпадку, калі пасля ўключэння DoH узнікнуць збоі з адпраўкай запытаў на сервер DoH (напрыклад, з-за яго блакіроўкі, парушэнні сеткавай складнасці або выхаду з ладу), браўзэр аўтаматычна верне сістэмныя налады DNS.
Мэтай правядзення эксперыменту з'яўляецца фінальная праверка рэалізацыі DoH і вывучэнне ўплыву прымянення DoH на прадукцыйнасць. Варта адзначыць, што фактычна падтрымка DoH была у кодавую базу Chrome яшчэ ў лютым, але для налады і ўключэнні DoH запуск Chrome са спецыяльным сцягам і невідавочным наборам опцый.
Нагадаем, што DoH можа апынуцца карысным для выключэння ўцечак звестак аб запытаных імёнах хастоў праз DNS-серверы правайдэраў, дужання з MITM-атакамі і падменай DNS-трафіку (напрыклад, пры падлучэнні да публічных Wi-Fi), супрацьстаянні блакаванням на ўзроўні DNS (DoH не можа замяніць VPN у вобласці абыходу блакіровак, рэалізаваных на ўзроўні DPI) або для арганізацыі працы ў выпадку немагчымасці прамога звароту да DNS-серверам (напрыклад, пры працы праз проксі). Калі ў звычайнай сітуацыі DNS-запыты наўпрост адпраўляюцца на вызначаныя ў канфігурацыі сістэмы DNS-серверы, то ў выпадку DoH запыт на вызначэнне IP-адрасу хаста інкапсулюецца ў трафік HTTPS і адпраўляецца на HTTP-сервер, на якім рэзавер апрацоўвае запыты праз Web API. Існуючы стандарт DNSSEC выкарыстоўвае шыфраванне толькі для аўтэнтыфікацыі кліента і сервера, але не абараняе трафік ад перахопу і не гарантуе канфідэнцыйнасць запытаў.
Крыніца: opennet.ru