Компании Cloudflare, Apple и Fastly совместно разработали и начали процесс стандартизации технологии ODoH (Oblivious DNS over HTTPS) с реализацией варианта DNS over HTTPS, сохраняющего конфиденциальность пользователя и не позволяющей резолверу узнать его IP-адрес. Одной из проблем DNS и DNS over HTTPS является утечка данных, возникающая из-за наличия у DNS-сервера возможности сопоставления отправляемых запросов с IP-адресом пользователя. Так как клиент отправляет запросы напрямую, DNS-сервер изначально знает его IP-адрес и все домены к которым пытается обратиться пользователь.
Для решения указанной проблемы в ODoH дополнительно вводится промежуточный узел - прокси, который перенаправляет запросы клиента к DNS-серверу и транслирует через себя ответы. Запросы и ответы дополнительно шифруются с использованием открытых ключей, что не позволяет прокси определить содержимое или подменить DNS-сообщения. Таким образом, прокси знает IP-адрес пользователя, но не может определить какие домены запрашивает пользователь. Со своей стороны DNS-сервер видит запрашиваемые домены (может расшифровать запрос и отправить шифрованный ответ), но не знает кто их запросил, так как все запросы приходят с общего IP-адреса прокси.
Необходимые для поддержки ODoH изменения в клиенте сводятся к добавлению дополнительного слоя шифрования для скрытия трафика от прокси. Кроме штатного TLS-шифрования, применяемого для защиты от транзитного перехвата в ходе MiTM-атак, дополнительно применяется аутентифицированное сквозное шифрование сообщений между клиентом и сервером, основанное на механизме HPKE (Hybrid Public Key Encryption). Открытый ключ для шифрования клиент получает через DNS (с верификацией DNSSEC) в одном из полей с дополнительными ресурсами. Использование данного ключа позволяет DNS-серверу расшифровать запросы клиента. Ключи для шифрования ответа каждый раз генерируются клиентом и отправляются внутри зашифрованного публичным ключом запроса.
Важной особенностью является то, что кроме выбора прокси выбор DNS-сервера, к которому будет отравлено обращение через прокси, производится клиентом (клиент сам выбирает сервер и использует привязанный к нему ключ, например, выбирает прокси Google, а сервер Cloudflare, а прокси не может скрыто перенаправить запрос на другой сервер, подконтрольный тому же владельцу). Подобная особенность позволяет кроме обеспечения конфиденциальности использовать прокси для отказоустойчивости и балансировки нагрузки - клиент может распределять запросы между разными резолверами, а в случае отказа направить запрос другому DNS-серверу. Также можно отметить, что принимающий запросы ODoH обработчик не обязательно должен быть DNS-сервером, он может как встраиваться в DNS-сервер, так выступать прослойкой, обращающейся к внешнему резолверу.
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, начал процесс стандартизации спецификации ODoH, которая в настоящий момент находится на стадии черновика. Для развёртывания узлов ODoH подготовлены открытые реализации клиентских и серверных компонентов ODoH, а также универсальные библиотеки.
Доступны три реализации клиентских утилит для отправки запросов (odoh-client, odoh-client-go и odoh-client-rs) и библиотек (odoh-rs, odoh-go, odoh), написанные на языках Rust и Go. Для запуска серверов предлагается odoh-server, написанный на языке Go и включающий рализацию прокси и резолвера. Поддержка ODoH интегрирована в cloudflared и резолвер Cloudflare, т.е. DNS-сервис 1.1.1.1 уже способен принимать запросы ODoH от прокси. Независимые прокси запущены проектами PCCW, SURF и Equinix.
Источник статьи: https://www.opennet.ru/opennews/art.shtml?num=54228
Для решения указанной проблемы в ODoH дополнительно вводится промежуточный узел - прокси, который перенаправляет запросы клиента к DNS-серверу и транслирует через себя ответы. Запросы и ответы дополнительно шифруются с использованием открытых ключей, что не позволяет прокси определить содержимое или подменить DNS-сообщения. Таким образом, прокси знает IP-адрес пользователя, но не может определить какие домены запрашивает пользователь. Со своей стороны DNS-сервер видит запрашиваемые домены (может расшифровать запрос и отправить шифрованный ответ), но не знает кто их запросил, так как все запросы приходят с общего IP-адреса прокси.
Необходимые для поддержки ODoH изменения в клиенте сводятся к добавлению дополнительного слоя шифрования для скрытия трафика от прокси. Кроме штатного TLS-шифрования, применяемого для защиты от транзитного перехвата в ходе MiTM-атак, дополнительно применяется аутентифицированное сквозное шифрование сообщений между клиентом и сервером, основанное на механизме HPKE (Hybrid Public Key Encryption). Открытый ключ для шифрования клиент получает через DNS (с верификацией DNSSEC) в одном из полей с дополнительными ресурсами. Использование данного ключа позволяет DNS-серверу расшифровать запросы клиента. Ключи для шифрования ответа каждый раз генерируются клиентом и отправляются внутри зашифрованного публичным ключом запроса.
Важной особенностью является то, что кроме выбора прокси выбор DNS-сервера, к которому будет отравлено обращение через прокси, производится клиентом (клиент сам выбирает сервер и использует привязанный к нему ключ, например, выбирает прокси Google, а сервер Cloudflare, а прокси не может скрыто перенаправить запрос на другой сервер, подконтрольный тому же владельцу). Подобная особенность позволяет кроме обеспечения конфиденциальности использовать прокси для отказоустойчивости и балансировки нагрузки - клиент может распределять запросы между разными резолверами, а в случае отказа направить запрос другому DNS-серверу. Также можно отметить, что принимающий запросы ODoH обработчик не обязательно должен быть DNS-сервером, он может как встраиваться в DNS-сервер, так выступать прослойкой, обращающейся к внешнему резолверу.
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, начал процесс стандартизации спецификации ODoH, которая в настоящий момент находится на стадии черновика. Для развёртывания узлов ODoH подготовлены открытые реализации клиентских и серверных компонентов ODoH, а также универсальные библиотеки.
Доступны три реализации клиентских утилит для отправки запросов (odoh-client, odoh-client-go и odoh-client-rs) и библиотек (odoh-rs, odoh-go, odoh), написанные на языках Rust и Go. Для запуска серверов предлагается odoh-server, написанный на языке Go и включающий рализацию прокси и резолвера. Поддержка ODoH интегрирована в cloudflared и резолвер Cloudflare, т.е. DNS-сервис 1.1.1.1 уже способен принимать запросы ODoH от прокси. Независимые прокси запущены проектами PCCW, SURF и Equinix.
Источник статьи: https://www.opennet.ru/opennews/art.shtml?num=54228