Cloudflare, Apple и Fastly объявили о создании нового протокола DNS

Cloudflare, Apple и Fastly заявили о разработке нового стандарта DNS, который отделяет IP-адреса от запросов. Oblivious DNS over HTTPS (ODoH) имеет открытый исходный код.

Обычная система доменных имен (DNS) сопоставляет используемые доменные имена, такие как cloudflare.com, с IP-адресами и другой информацией, необходимой для подключения к этому домену. DNS-запросы отправляются в открытом виде. Это означает, что на сетевом пути между устройством и преобразователем DNS может появиться третье лицо, которое будет видеть и запрос с именем хоста, и IP-адрес гаджета.

Чтобы защитить DNS от постороннего вмешательства, был разработан стандарт DNS через HTTPS (DoH) и DNS через TLS (DoT). Оба протокола предотвращают перехват, перенаправление или изменение запросов между клиентом и преобразователем. Клиентская поддержка DoT и DoH растет, она реализована в последних версиях Firefox, iOS и других. Однако пока Cloudflare остается одним из немногих провайдеров, предлагающих общедоступную услугу DoH/DoT.

Ключевой компонент ODoH — это прокси, не связанный с целевым преобразователем. Протокол запустили при поддержке прокси-партнеров, включая PCCW, SURF и Equinix.

ODoH добавляет уровень шифрования с открытым ключом, а также сетевой прокси между клиентами и серверами DoH, например 1.1.1.1. Комбинация этих двух дополнительных элементов гарантирует, что только пользователь имеет доступ как к сообщениям DNS, так и к собственному IP-адресу одновременно. Цель расшифровывает запросы, зашифрованные клиентом, через прокси. Точно так же цель шифрует ответы и возвращает их прокси. При этом цель видит только запрос и IP-адрес прокси, расшифровывая их с помощью ключа DNSSEC. Прокси-сервер не видит сообщений DNS и не может идентифицировать, читать или изменять ни запрос, отправляемый клиентом, ни ответ, возвращаемый целью. Клиент может выбрать и изменить свои прокси и цели в любой момент. Таким образом, успешная атака может быть реализована, только если и прокси, и цель скомпрометированы.

Добавленное шифрование является «сквозным» между клиентом и целью и не зависит от шифрования на уровне соединения, обеспечиваемого TLS/HTTPS. Для поддержки функций прокси требуется два отдельных соединения TLS. В частности, прокси завершает TLS-соединение от клиента и инициирует другое TLS-соединение с целью. ODoH дополнительно шифрует сообщения между клиентом и целью, поэтому прокси-сервер не имеет доступа к содержимому сообщения.

Клиенты передают зашифрованные запросы прокси-серверу через HTTPS-соединение. После получения прокси-сервер пересылает запрос указанной цели. Затем цель дешифрует запрос, выдает ответ, отправляя запрос рекурсивному преобразователю, например, 1.1.1.1, и шифрует ответ. Зашифрованный запрос от клиента содержит инкапсулированный ключевой материал, из которого целевые объекты получают симметричный ключ шифрования ответа.

«Наряду с повышенной безопасностью и производительностью базовой глобальной сети PCCW, доступ к которой можно получить по запросу через Console Connect, производительность прокси-серверов в сети улучшена резолверами Cloudflare 1.1.1.1. Эта модель впервые полностью отделяет клиентский прокси от резолверов», — заявил Майкл Глинн, вице-президент по цифровым автоматизированным инновациям в PCCW Global

На диаграмме ниже показано кумулятивное распределение времени запроса/ответа в DoH, ODoH и DoH при передаче по сети Tor.

По сравнению с другими вариантами DNS, ориентированными на конфиденциальность, ODoH сокращает время запроса вдвое и более.

Открытый исходный код реализаций ODoH доступен на Rust, odoh-rs и Go, odoh-go.

Протокол поддерживается TLS-расширением ESNI (Encrypted Server Name Indication), которое позволит передавать идентификатор запрошенного хоста в шифрованном виде. В 2018 году его разработали Mozilla, Cloudflare, Fastly и Apple.Источник

bigsun09
dig должна быть тоже на винде

ps похоже можно только через powershell замерить время nslookup.

fibi768 писал(а):

Не знаю, поможет ли данная технология обойти блокировки...

Не поможет. Шифрование DNS лишь позволит получать IP адреса заблокированных сайтов без ведома провайдера, но сайты обычно блокируются по IP, так что нужен ещё proxy.

monkdt писал(а):

bigsun09
dig должна быть тоже на винде

ps похоже можно только через powershell замерить время nslookup.

Штатно её нет, можно по мурзилке раскатать http://pyatilistnik.org/installing-dig-on-windows/

mikeone63
насколько я в гугле вижу люди просто измеряют время выхлопа команды nslookup в powershell

Интересно, как будет (и будет ли?) работать через такую схему EDNS0 с client subnet, которая нужна для нормальной работы GeoDNS? Или при использовании такой схемы рекурсор всегда будет видеть сеть/страну прокси вместо пользовательской?

ня

это же не обычный прокси с подменой адресов. Каждый провадер dns должен в этом случае создавать свои сервисы. Технологию можно скорее представить как vpn чем прокси

monkdt

Но если это больше похоже на vpn, и подмены адресов не происходит, то рекурсор будет знать адрес пользователя. А тогда схема не будет oblivious, ведь появится сторона, которая может следить за активностью пользователя.

Я всё-таки больше склоняюсь к тому, что они просто сломали GeoDNS в угоду приватности.

monkdt
mikeone63
Посмотрел на https://webopulsar.ru/test/
на http://nnmclub.to/
Смотрим DNS Lookup.

ipconfig /all | findstr /R "DNS Servers"
DNS-серверы. . . . . . . . . . . : 127.0.0.1 (SimpleDNSCrypt64)
Тут среднее 40 мс

ipconfig /all | findstr /R "DNS Servers"
DNS-серверы. . . . . . . . . . . : 1.1.1.1
Тут среднее 67 мс
Хотя по ощущениям - быстрее.

ipconfig /all | findstr /R "DNS Servers"
DNS-серверы. . . . . . . . . . . : 192.168.1.1 (роутер)
Тут среднее 82 мс

Но провайдер у меня в принципе слабый, да и подключение через 300 Мбит/с роутер (в реалии 65 Мбит/с)

ня
вы неверно представляете себе dns. Ее функция просто возвратить удобочитаемый адрес из базы к существующему ip. У самого же провайдера создается тунель который шифруется и его конечные адреса остаются неизменными. Даже если бы они изменились не играет никакой роли. Нам важны только ip -> dns имя чужих машин, а не собственных провайдера

fibi768 писал(а):

Не знаю, поможет ли данная технология обойти блокировки...

У нас заблокировали яндекс и вконтакте и еще другие ресурсы, но яндекс для меня самый болезненный удар. Гугл убогий по русскоязычному поиску, яндекс на много удобней и быстрее обновляется и возможности шире.

Попался бы в руки инициатор этих блокировок без охраны...

не пиши бред :смех:

bigsun09
да это и так очень быстро. SimpleDNSCrypt64 играет роль кэширующего сервера поэтому так быстро. У меня вообще по нулям. Спасибо, было интересно глянуть

Они придумали dns-proxy но с шифрованием? Т.е. просто добавляется третье лицо в середине?

monkdt писал(а):

резолв работает c очень приличной скоростью ( nnmclub.to Query time: 20 msec). Я так и не понял зачем нужен клиент? Cобрал растовую версию, думал сначала через него работает. Тестировал через демон cloudfared

Как эта технология помешает спецслужбам читать наши email и сообщения в мессенджерах?
Сразу отвечу: новый протокол dns этими самыми американскими спецслужбами и создан.

True Diamond

Цитата:

Как эта технология помешает спецслужбам читать наши email и сообщения в мессенджерах?

во первых не стоит обсуждать возможности власти которые по сути безграничны в пределах государства. А во вторых насколько я знаю сейчас фишинг остается очень действенным методом, т.е it-граммотность у большинства людей чуть выше нуля. После того, как я тут прочитал про шкафы с рутерами в отдельных домах в России, я бы в первую очередь озаботился, чтобы случайный вася пупкин не получил доступ к рутеру и сотворил простую mitm атаку с подменой адресов.

А можно просто задаться вопросом зачем крупнейшие фирмы тратят бешенные деньги и время на разработку таких сервисов. Наверное ради интереса )

Что еще добавить ?