Oblivious DoH (ODoH) та VPN: межі дволанкового захисту DNS

Широке впровадження протоколів шифрування доменних імен, таких як DNS-over-HTTPS (DoH, RFC 8484) та DNS-over-TLS (DoT, RFC 7858), стало вагомим кроком у розвитку мережевої безпеки. Ці стандарти захистили канал між пристроєм користувача та рекурсивним резолвером, унеможлививши перехоплення відкритих пакетів UDP через порт 53 інтернет-провайдерами чи зловмисниками у публічних точках Wi-Fi.

Проте класичний DoH породив новий парадокс конфіденційності: чутливі метадані зосередилися в руках обмеженої кількості провайдерів резолверів. Під час надсилання запиту до централізованих служб (таких як Cloudflare, Google Public DNS чи Quad9) один оператор одночасно дізнається:

1. Хто запитує: реальну публічну IP-адресу клієнта.
2. Що запитується: точне доменне ім'я сайту, який відвідують.

Ця концентрація інформації спонукала IETF розробити стандарт Oblivious DNS over HTTPS (ODoH, RFC 9230) та розширену концепцію Oblivious HTTP (OHTTP, RFC 9458). Хоча ODoH елегантно розділяє особу користувача та зміст запиту, існує поширена помилка, нібито ця технологія цілком замінює використання повноцінних тунелів VPN.

Поглиблений аналіз показує, що ODoH ефективно вирішує проблему на рівні резолвера, проте залишає відкритим фактичний вебтрафік, якщо з'єднання не захищене тунелем мережевого рівня.

Архітектура Oblivious DoH: розмежування особи та запиту

Головний принцип Oblivious DoH полягає у тому, що жодна окрема сторона не повинна володіти одночасно інформацією про IP-адресу користувача та ім'я цільового домену.

Для розриву цього зв'язку RFC 9230 впроваджує тристоронню схему, яка містить Клієнта (Client), Ретранслятор (Relay) та Цільовий резолвер (Target):

[ Клієнтський пристрій ]
           |
           | 1. Надсилання HPKE-зашифрованого запиту
           v
[ Вузол ретрансляції ODoH Relay ] (Бачить IP клієнта, не бачить вміст запиту)
           |
           | 2. Видалення IP клієнта, пересилання шифротексту
           v
[ Цільовий резолвер ODoH Target ] (Розшифровує запит, знає домен, не знає IP)
           |
           | 3. Розв'язує DNS, шифрує відповідь ключем сесії
           +-----> Повернення через Relay -----> Клієнтський пристрій

1. Гібридне шифрування відкритим ключем (HPKE)

Перед створенням запиту клієнт завантажує публічний ключ конфігурації цільового сервера (odohconfig) через надійні канали виявлення HTTPS.

За допомогою механізму HPKE (RFC 9180) клієнт запаковує бінарний DNS-пакет у сесійний симетричний ключ, згенерований на базі відкритого ключа Target. Отриманий зашифрований пакет передається на вузол Relay.

2. Принцип роботи проміжного вузла (Relay)

Вузол Relay отримує криптографічний конверт через звичайну сесію HTTPS. Не володіючи приватним ключем сервера Target, Relay не має технічної можливості розшифрувати вміст.

Його завдання полягає у відокремленні початкової IP-адреси клієнта від заголовка пакета, підміні її власною IP-адресою та передаванні непрозорого блока даних до вузла Target.

3. Опрацювання на цільовому резолвері (Target)

Сервер Target отримує пакет від IP-адреси Relay і не володіє жодними відомостями про справжнього користувача.

Використовуючи власний приватний ключ, Target розшифровує повідомлення, виконує рекурсивний пошук у базі DNS, шифрує відповідь узгодженим симетричним контекстом HPKE і передає її зворотним маршрутом через Relay клієнту.

У такий спосіб Relay знає, хто звернувся, але не знає, куди; Target знає, який сайт шукають, але не знає, хто саме.

Структурні обмеження технології Oblivious DoH

Хоча ODoH чудово захищає процес визначення IP-адрес сайтів, аналіз поведінки системи в цілому виявляє помітні слабкі місця:

1. Відкритість IP-адреси під час основного вебз'єднання

Запит до DNS є лише першим кроком. Після отримання цільової IP-адреси операційна система встановлює безпосереднє TCP- або QUIC-з'єднання з вебсервером.

У цей момент пристрій відправляє стандартні мережеві пакети, де у заголовках відкрито міститься справжня IP-адреса користувача. Ба більше, якщо сайт не підтримує розширення Encrypted Client Hello (ECH), ім'я домену відкрито транслюється у полі SNI.

Таким чином, ODoH захищає запит від оператора DNS, але вебсайт, маркетингові трекери та місцевий інтернет-провайдер бачать кожен крок користувача.

2. Залежність від невтручання та відсутності змови

Безпека схеми RFC 9230 базується на обов'язковому припущенні, що оператори Relay та Target є незалежними та не взаємодіють між собою поза протоколом.

Якщо обидва сервери належать одній телекомунікаційній корпорації чи обмінюються системними журналами, співставлення часу передавання та розмірів пакетів дозволяє миттєво відновити зв'язок між користувачем і доменом.

3. Зростання затримки та регіональні невідповідності

Маршрутизація трафіку через два незалежні вузли неодмінно збільшує час обігу пакетів (RTT). Стандартний запит DoH виконує один транзит, тоді як ODoH потребує двох послідовних з'єднань через різні автономні системи.

Окрім цього, оскільки цільовий резолвер бачить тільки IP-адресу вузла Relay, він не може застосовувати технологію EDNS Client Subnet (ECS) без розкриття приватності. В результаті авторитетні сервери можуть повертати IP-адреси CDN, географічно оптимізовані під дата-центр Relay, а не під місто клієнта, що негативно позначається на швидкості потокового завантаження.

Порівняння протоколів DNS та тунелювання Layer 3

Різниця між прикладними проксі-рішеннями (Layer 7) та комплексною ізоляцією мережевого рівня (Layer 3) наведена у таблиці:

Чому системна приватність вимагає захисту на третьому рівні

Спроби захистити мережеву активність комбінуванням окремих інструментів прикладного рівня (DoH, ODoH, плагіни браузерів) неминуче створюють технічні розриви. Фоновий системний трафік — протоколи виявлення пристроїв, повідомлення ICMP, оновлення програмного забезпечення — продовжує транслюватися у відкритому вигляді через локальний адаптер.

Віртуальна приватна мережа третього рівня Layer 3 захищає з'єднання на фундаментальному рівні:

1. Єдина маскувальна оболонка: Усі дані, що виходять із пристрою — системні DNS-запити, передавання файлів чи сесії месенджерів — упаковуються в нові криптографічні пакети, адресовані лише до шлюзу VPN.
2. Локальне опрацювання DNS на виході: В архітектурі RiceGuard рекурсивне розв'язання доменних імен відбувається на внутрішньому інтерфейсі loopback вихідного шлюзу VPN. Запити ніколи не виходять на сторонні сервери-посередники. Вихідний запит здійснюється від спільної IP-адреси шлюзу, що відділяє особу користувача від запиту без потреби у зайвих транзитних вузлах.
3. Глобальний захист системи: На відміну від ODoH, який вимагає налаштування в кожній окремій програмі, тунель Layer 3 діє на рівні віртуального мережевого інтерфейсу ядра (tun/tap), автоматично захищаючи абсолютно всі мережеві запити.

Комплексний захист у системі VPNRice

Фахівці розуміють, що ODoH є помітним академічним досягненням, проте надійна безпека на практиці забезпечується цілісним захистом усього мережевого стека.

Архітектура VPNRice будує безпечний контур на всіх етапах взаємодії:

На мережевому рівні протокол RiceGuard інкапсулює кожен пакет за допомогою алгоритму ChaCha20-Poly1305. Провайдери зв'язку та інші учасники локальної мережі бачать лише однорідний потік шифрованих пакетів UDP, спрямованих до захищених серверів Anycast.

Усі запити DNS від операційної системи потрапляють всередину тунелю й опрацьовуються локальними резолверами VPNRice без збереження журналів активності. Маскуючи IP-адресу клієнта як під час обробки DNS, так і під час усіх подальших з'єднань з вебсайтами, VPNRice досягає повної конфіденційності для всього вашого інтернет-трафіку. Завантажити VPNRice.