Chrome 78 ще започне да експериментира с активирането на DNS-over-HTTPS

Следване Mozilla компания Google съобщава относно намерението да се проведе експеримент за тестване на внедряването на „DNS през HTTPS“ (DoH, DNS през HTTPS), което се разработва за браузъра Chrome. Chrome 78, планиран за 22 октомври, ще има някои потребителски категории по подразбиране преведено да използвате DoH. Само потребители, чиито текущи системни настройки посочват определени DNS доставчици, разпознати като съвместими с DoH, ще участват в експеримента за активиране на 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), Cleanbrowsing (185.228.168.168. 185.228.169.168, 185.222.222.222) и DNS.SB (185.184.222.222, XNUMX). Ако DNS настройките на потребителя указват един от гореспоменатите DNS сървъри, DoH в Chrome ще бъде активиран по подразбиране. За тези, които използват DNS сървъри, предоставени от техния местен интернет доставчик, всичко ще остане непроменено и системният резолвер ще продължи да се използва за DNS заявки.

Важна разлика от внедряването на DoH във Firefox, което постепенно активира DoH по подразбиране ще започне още в края на септември е липсата на обвързване с една DoH услуга. Ако във Firefox по подразбиране употребяван CloudFlare DNS сървър, тогава Chrome само ще актуализира метода на работа с DNS до еквивалентна услуга, без да променя DNS доставчика. Например, ако потребителят е посочил DNS 8.8.8.8 в системните настройки, тогава Chrome ще го направи активиран Google DoH услуга („https://dns.google.com/dns-query“), ако DNS е 1.1.1.1, тогава Cloudflare DoH услуга („https://cloudflare-dns.com/dns-query“) И и т.н.

Ако желае, потребителят може да активира или деактивира DoH с помощта на настройката „chrome://flags/#dns-over-https“. Поддържат се три режима на работа: защитен, автоматичен и изключен. В „сигурен“ режим хостовете се определят само въз основа на предварително кеширани защитени стойности (получени чрез защитена връзка) и заявки чрез DoH; не се прилага резервно връщане към обикновен DNS. В „автоматичен“ режим, ако DoH и защитеният кеш не са налични, данните могат да бъдат извлечени от незащитения кеш и достъпни чрез традиционния DNS. В режим „изключен“ първо се проверява споделеният кеш и ако няма данни, заявката се изпраща през системния 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 сървъра, където резолверът обработва заявки чрез уеб API. Съществуващият стандарт DNSSEC използва криптиране само за удостоверяване на клиента и сървъра, но не защитава трафика от прихващане и не гарантира поверителността на заявките.

Източник: opennet.ru

Добавяне на нов коментар