DNS-over-HTTPS включений за промовчанням у Firefox для користувачів зі США

Firefox оголосив про включення за умовчанням режиму DNS поверх HTTPS (DoH, DNS over HTTPS) для користувачів зі США. Шифрування DNS-трафіку сприймається як важливий чинник захисту користувачів. Починаючи з сьогоднішнього дня, у всіх нових установках, виконаних користувачами зі США, DoH активовано за замовчуванням. Існуючих користувачів із США планується переключити на DoH протягом кількох тижнів. У Євросоюзі та інших країнах активувати DoH за умовчанням поки що не планують.

Після активації DoH користувачу виводиться попередження, яке дозволяє за бажання відмовитися від звернення до централізованих DoH-серверів DNS і повернутися до традиційної схеми надсилання незашифрованих запитів до DNS-сервера провайдера. Замість розподіленої інфраструктури резолверів DNS, DoH використано прив'язку до певного DoH-сервісу, який може розглядатися як єдина точка відмови. В даний час пропонується робота через два DNS-провайдери - CloudFlare (за замовчуванням) та NextDNS.

Змінити провайдера або вимкнути DoH можна в налаштуваннях мережного з'єднання. Наприклад, можна вказати альтернативний сервер DoH "https://dns.google/dns-query" для звернення до серверів Google, "https://dns.quad9.net/dns-query" - Quad9 та "https://doh .opendns.com/dns-query" - OpenDNS. В about:config також передбачено налаштування network.trr.mode, через яке можна змінити режим роботи DoH: значення 0 повністю відключає DoH; 1 - використовується DNS або DoH, залежно від того, що швидше; 2 - використовується DoH за замовчуванням, а DNS як запасний варіант; 3 - використовується лише DoH; 4 - режим дзеркалювання при якому DoH та DNS задіяні паралельно.

Нагадаємо, що DoH може виявитися корисним для виключення витоків відомостей про імена хостів через DNS-сервери провайдерів, боротьби з MITM-атаками і заміною DNS-трафіку (наприклад, при підключенні до публічних Wi-Fi), протистояння блокувань на рівні DNS (DoH не може замінити VPN в області обходу блокувань, реалізованих на рівні DPI) або для роботи в разі неможливості прямого звернення до DNS-серверів (наприклад, при роботі через проксі). Якщо у звичайній ситуації DNS-запити безпосередньо відправляються на визначені в конфігурації системи DNS-сервери, то у разі DoH запит на визначення IP-адреси хоста інкапсулюється в трафік HTTPS і відправляється на сервер HTTP, на якому резолвер обробляє запити через Web API. Існуючий стандарт DNSSEC використовує шифрування лише для автентифікації клієнта та сервера, але не захищає трафік від перехоплення та не гарантує конфіденційність запитів.

Для відбору пропонованих у Firefox провайдерів DoH сформульовані|вимоги| третім особам і має розкривати інформацію про способи обробки даних. Сервіс також має дати зобов'язання не цензурувати, не фільтрувати, не втручатися та не блокувати DNS-трафік, за винятком ситуацій, передбачених законодавством.

Для визначення корпоративних резолверів виконуються перевірки нетипових доменів першого рівня (TLD) та повернення системним резолвером інтранет-адрес. Для визначення включення батьківського контролю здійснюється спроба резолвінгу імені exampleadultsite.com і якщо результат не збігається з фактичним IP, вважається активним блокування дорослого контенту на рівні DNS. Як ознаки також перевіряються IP-адреси Google і YouTube щодо їх заміни на restrict.youtube.com, forcesafesearch.google.com і restrictmoderate.youtube.com. Дані перевірки дають можливість атакуючим, контролюючим роботу резолвера або здатним втрутитися в трафік, симулювати подібну поведінку для відключення шифрування DNS-трафіку.

Робота через єдиний DoH-сервіс також потенційно може призвести до проблем з оптимізацією трафіку в мережах доставки контенту, які виконують балансування трафіку з використанням DNS (DNS-сервер CDN-мережі формує відповідь, враховуючи адресу резолвера та видає найближчий хост для отримання контенту ). Надсилання DNS-запиту з найближчого до користувача резолвера в таких CDN призводить до повернення адреси найближчого до користувача хоста, але при надсиланні DNS-запиту з централізованого резолвера буде видана адреса хоста, найближча до сервера DNS-over-HTTPS. Тестування на практиці показало, що застосування DNS-over-HTTP при використанні CDN практично не призводило до затримок перед початком передачі контенту (для швидких з'єднань затримки не перевищували 10 мілісекунд, а повільних каналах зв'язку спостерігалося навіть прискорення роботи). Для передачі резолверу CDN відомості про розташування клієнта також було розглянуто застосування розширення EDNS Client Subnet.

Інші новини