Cloudflare, Apple и Fastly представили сохраняющий конфиденциальность вариант DNS over HTTPS
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Компании 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-сервера, к которому будет отравлено обращение через прокси, производится клиентом (клиент сам выбирает сервер и использует привязанный к нему ключ, т.е. прокси не может скрыто перенаправить запрос на другой сервер). Подобная особенность позволяет кроме обеспечения конфиденциальности использовать прокси для отказоустойчивости и балансировки нагрузки, распределяя запросы между разными резолверами или в случае отказа направляя запрос другому резолверу. Также можно отметить, что принимающий запросы 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.
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://blog.cloudflare.com/ob...)
- OpenNews: В Chrome для Android включена поддержка DNS-over-HTTPS
- OpenNews: Инициатива DNS flag day 2020 для решения проблем с фрагментацией и поддержкой TCP
- OpenNews: Ассоциации провайдеров США выступили против централизации при внедрении DNS-over-HTTPS
- OpenNews: Атака SAD DNS для подстановки фиктивных данных в кэш DNS
- OpenNews: В следующем выпуске Android появится поддержка "DNS over TLS"
Похожие новости:
- [Информационная безопасность, Сетевые технологии, DNS] Cloudflare, Apple и Fastly объявили о создании нового протокола DNS
- [Информационная безопасность, Криптография, Законодательство в IT] Власти Казахстана снова принуждают пользователей устанавливать сертификат, чтобы читать зашифрованную переписку
- Казахстан возобновил попытки перехвата HTTPS-трафика
- [Информационная безопасность, Администрирование доменных имен] Сайты региональных органов власти: все еще печальнее, чем у федералов
- [Информационная безопасность] Популярные сайты все еще уязвимы для массовой DDoS-атаки
- [Администрирование доменных имен, Анализ и проектирование систем, DNS, ООП, Хранение данных] Доменный регистратор, или Туда и обратно
- [Настройка Linux, Системное администрирование] Файловый сервер на Samba, видимый отовсюду
- [Java, DNS] 25 ноября, в 15:00 пройдет онлайн-семинар по внедрению поддержки IDN-доменов и EAI-адресов
- [Firefox, Браузеры] В Firefox 83 внедрили режим «только HTTPS»
- Атака SAD DNS для подстановки фиктивных данных в кэш DNS
Теги для поиска: #_dns, #_doh, #_odoh, #_https
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 07:08
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Компании 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-сервера, к которому будет отравлено обращение через прокси, производится клиентом (клиент сам выбирает сервер и использует привязанный к нему ключ, т.е. прокси не может скрыто перенаправить запрос на другой сервер). Подобная особенность позволяет кроме обеспечения конфиденциальности использовать прокси для отказоустойчивости и балансировки нагрузки, распределяя запросы между разными резолверами или в случае отказа направляя запрос другому резолверу. Также можно отметить, что принимающий запросы 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. =========== Источник: OpenNet.RU =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 07:08
Часовой пояс: UTC + 5