Шифрований DNS: DoH і DoT

Попереднє заняття описало звичайний DNS-пошук як листівку: читабельну для будь-кого, хто обробляє її дорогою. Існує два стандарти IETF, щоб покласти цю листівку в конверт: DNS через TLS (DoT, RFC 7858) і DNS через HTTPS (DoH, RFC 8484). Обидва шифрують той самий пошук; вони переважно різняться тим, як його переносять.

DNS через TLS

RFC 7858 прямо заявляє свою мету: «шифрування, надане TLS, усуває можливості для підслуховування та втручання в DNS-запити на шляху», вирішуючи те, що «майже всі DNS-запити надсилаються незашифрованими, що робить їх вразливими до підслуховування зловмисником». DoT використовує власний виділений порт, 853, а не звичайний порт 53. RFC пояснює чому: «ця рекомендація проти використання порту 53 для DNS через TLS покликана уникнути ускладнень при виборі використання чи невикористання TLS і зменшити ризик атак пониження версії».

DNS через HTTPS

RFC 8484 обирає інший шлях: «кожна пара DNS-запит-відповідь відображається в HTTP-обмін», що переноситься через той самий порт 443, який використовує звичайний трафік HTTPS. RFC зазначає, що це має побічну вигоду: «типовий порт HTTPS 443 і можливість змішувати трафік DoH з іншим трафіком HTTPS у тому самому з’єднанні можуть стримувати непривілейовані пристрої на шляху від втручання в операції DNS», бо пошук важче виокремити й заблокувати, коли він виглядає як будь-який інший вебзапит.

Що приховує шифрування, а що досі ні

Обидва стандарти заважають оператору мережі чи підслуховувачу Wi-Fi читати ваші пошуки під час передавання. Жоден не приховує їх від резолвера, якому ви їх надіслали. RFC 8484 прямо каже, що DoH не змінює те, кого може бачити сам сервер: він зазначає, що «різні способи транспортування DNS-запитів і відповідей справді надають дані, які можна використати для зіставлення запитів», і що звичайна вебмеханіка на кшталт IP-адрес клієнта, файлів cookie та інформації про сесію TLS означає, що «DoH, наскільки відомо, не додає нових проблем понад ті, що пов’язані з HTTPS» на боці сервера. RFC 7858 так само зазначає, що DoT «не вирішує інші проблеми безпеки в DNS» і що «навіть із зашифрованими повідомленнями, добре розташована сторона може вловити певні деталі з аналізу часу й розміру повідомлень». Коротко: шифрований DNS переміщує те, хто бачить ваші пошуки, назад до оператора резолвера, якого ви обрали, а не прибирає видимість повністю.

Є ще одна прогалина, яку варто знати. Шифрування DNS-пошуку саме по собі не приховує, до якого сайту ви потім з’єднуєтеся: рукостискання TLS, що йде далі, зазвичай містить ім’я хоста у відкритому вигляді. Як пояснює Cloudflare щодо вказівки імені сервера (SNI), «SNI включає ім’я хоста в повідомлення Client Hello, тобто найперший крок рукостискання TLS» — надісланий до того, як встановлено шифрування. Розширення під назвою Encrypted SNI (ESNI), за тим самим джерелом, «доповнює розширення SNI, шифруючи частину SNI в Client Hello», що «заважає будь-кому, хто підслуховує між клієнтом і сервером, бачити, який сертифікат запитує клієнт». Підтримка приховування SNI досі залежить від того, чи погоджуються на це і браузер, і сайт, і поки що працює не в кожному з’єднанні.

Як це підтримує macOS

Apple документує налаштування DNS для Mac, iPhone та iPad, що робить саме це: воно дозволяє пристрою «спрямовувати DNS-запити пристрою через зашифрований DNS-сервер за допомогою DNS через HTTPS чи DNS через TLS». Це постачається як конфігураційний профіль, що може обмежити зашифрований резолвер конкретними доменами через «додаткові домени збігу» чи застосовуватися лише в певних мережах за допомогою «правил за потреби», що можуть звірятися, наприклад, з ідентифікатором мережі SSID.