Улучшение конфиденциальности DNS с помощью Oblivious DoH в 1.1.1.1

Сегодня мы объявляем о поддержке нового предлагаемого стандарта DNS, разработанного в соавторстве с инженерами Cloudflare, Apple и Fastly, который отделяет IP-адреса от запросов, так что ни один объект не может видеть оба одновременно. Более того, мы сделали доступным исходный код, так что любой может попробовать ODoH или запустить свой собственный сервис ODoH!

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

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

Cloudflare стремится к конфиденциальности конечных пользователей. Пользователи нашей общедоступной службы распознавания DNS защищены строгой проверенной политикой конфиденциальности. Однако для некоторых доверие Cloudflare к конфиденциальной информации о запросах является препятствием для принятия, даже при такой строгой политике конфиденциальности. Вместо того, чтобы полагаться на политику конфиденциальности и аудит, что, если бы мы могли дать пользователям возможность удалить эту полосу с техническими гарантиями?

Сегодня Cloudflare и партнеры запускают поддержку протокола, который делает именно это: Oblivious DNS over HTTPS, или сокращенно ODoH.

Партнеры ODoH:

Мы рады запустить ODoH с несколькими ведущими партнерами по запуску, которые в равной степени привержены конфиденциальности.

Ключевым компонентом ODoH является прокси, не связанный с целевым преобразователем. Сегодня мы запускаем ODoH с несколькими ведущими партнерами по прокси, включая PCCW, SURF и Equinix.

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

«Мы сотрудничаем с Cloudflare, чтобы улучшить конфиденциальность пользователей с помощью ODoH. Переход к ODoH - это настоящий сдвиг парадигмы, когда конфиденциальность пользователей или IP-адрес не раскрываются ни одному провайдеру, что приводит к истинной конфиденциальности. С запуском пилотного проекта ODoH мы присоединяемся к мощи сети Cloudflare, чтобы решать задачи любых пользователей по всему миру. Переход на ODoH - это не только смена парадигмы, но и подчеркивание того, насколько важна конфиденциальность для любых пользователей, чем когда-либо, особенно в 2020 году. Это перекликается с нашей основной направленностью и убеждением в отношении конфиденциальности». - Йост ван Дейк, технический менеджер по продукции, SURF

Как работает Oblivious DNS over HTTPS (ODoH)?

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

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

Вместе добавленное шифрование и проксирование обеспечивают следующие гарантии:

Цель видит только запрос и IP-адрес прокси.
Прокси-сервер не видит сообщений DNS и не может идентифицировать, читать или изменять ни запрос, отправляемый клиентом, ни ответ, возвращаемый целью.
Только предполагаемая цель может прочитать содержимое запроса и дать ответ.

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

Один из аспектов этой системы, который стоит выделить, заключается в том, что цель отделена от рекурсивного преобразователя восходящего потока, который выполняет разрешение DNS. На практике мы ожидаем, что цель будет такой же. Фактически, 1.1.1.1 теперь одновременно и рекурсивный преобразователь, и цель! Нет причин, по которым цель должна существовать отдельно от любого преобразователя. Если они разделены, то цель может выбирать преобразователи и просто действовать как посредник. Помните, что единственное реальное требование состоит в том, чтобы прокси и цель никогда не вступали в сговор.

Кроме того, что важно, клиенты полностью контролируют выбор прокси и цели. Без необходимости в программах, подобных TRR, клиенты могут иметь конфиденциальность для своих запросов в дополнение к безопасности. Поскольку цель знает только о прокси, цель и любой восходящий преобразователь не обращают внимания на существование каких-либо клиентских IP-адресов. Важно отметить, что это дает клиентам больший контроль над своими запросами и способами их использования. Например, клиенты могут выбирать и изменять свои прокси и цели в любое время и по любой причине!

Поток сообщений ODoH

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

Весь процесс начинается с клиентов, которые шифруют свой запрос к цели с помощью HPKE. Клиенты получают открытый ключ цели через DNS, где он объединяется в запись ресурса HTTPS и защищается DNSSEC. Когда TTL для этого ключа истекает, клиенты запрашивают новую копию ключа по мере необходимости (так же, как они сделали бы для записи A/AAAA, когда истекает TTL этой записи). Использование проверенного DNSSEC открытого ключа цели гарантирует, что только предполагаемая цель может расшифровать запрос и зашифровать ответ.

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

Затем этот ответ отправляется обратно на прокси, а затем пересылается клиенту. Все коммуникации проходят проверку подлинности и конфиденциальны, поскольку эти DNS-сообщения зашифрованы сквозным шифрованием, несмотря на то, что они передаются по двум отдельным HTTPS-соединениям (клиент-прокси и прокси-цель). Сообщение, которое в противном случае представляется прокси-серверу как открытый текст, на самом деле является зашифрованным искажением.

А что насчет производительности? Должен ли я торговать производительностью, чтобы получить конфиденциальность?

Мы провели много измерений, чтобы выяснить это, и будем делать больше по мере более широкого развертывания ODoH. Наш первоначальный набор конфигураций измерений охватывал города в США, Канаде и Бразилии. Важно отметить, что наши измерения включают не только 1.1.1.1, но также 8.8.8.8 и 9.9.9.9. Полный набор измерений пока задокументирован для открытого доступа.

В этих измерениях было важно отделить стоимость проксирования и дополнительного шифрования от стоимости настройки TCP и TLS-соединения. Это потому, что затраты TLS и TCP в любом случае несет DoH. Итак, в нашей настройке мы «подготовили» измерения, установив соединение один раз и повторно используя это соединение для всех измерений. Мы сделали это как для DoH, так и для ODoH, поскольку в любом случае могла использоваться одна и та же стратегия.

Первое, что можно сказать с уверенностью, это то, что дополнительное шифрование маргинально. Мы знаем это, потому что случайным образом выбрали 10 000 доменов из набора данных Tranco Million и измерили как шифрование записи A с другим открытым ключом, так и ее расшифровку. Дополнительные затраты между проксируемым запросом/ответом DoH и его аналогом ODoH неизменно составляют менее 1 мс на 99-м процентиле.

Однако конвейер запроса-ответа ODoH - это гораздо больше, чем просто шифрование. Очень полезный способ взглянуть на измерения - это посмотреть на диаграмму совокупного распределения. Если вы знакомы с этими типами диаграмм, перейдите к следующему абзацу. В отличие от большинства диаграмм, где мы начинаем с оси X, с кумулятивными распределениями мы часто начинаем с оси Y.

На диаграмме ниже показано кумулятивное распределение времени запроса/ответа в DoH, ODoH и DoH при передаче по сети Tor. Пунктирная горизонтальная линия, которая начинается слева от 0,5, соответствует отметке 50%. Вдоль этой горизонтальной линии для любой построенной кривой часть кривой ниже пунктирной линии составляет 50% точек данных. Теперь посмотрим на ось абсцисс, которая является мерой времени. Строки, которые появляются слева, быстрее, чем строки справа. Последняя важная деталь заключается в том, что ось X нанесена в логарифмическом масштабе. Что это значит? Обратите внимание, что расстояние между помеченными маркерами (10x) в совокупных распределениях одинаково, но «X» является показателем степени и представляет порядки величины. Итак, хотя разница во времени между первыми двумя маркерами составляет 9 мс, разница между 3-м и 4-м маркерами составляет 900 мс.

На этой диаграмме средняя кривая представляет измерения ODoH. Мы также измерили производительность альтернатив, сохраняющих конфиденциальность, например, запросов DoH, передаваемых по сети Tor, как показано правой кривой на диаграмме. (Дополнительные сохраняющие конфиденциальность альтернативы отражены в техническом отчете открытого доступа.) По сравнению с другими вариантами DNS, ориентированными на конфиденциальность, ODoH сокращает время запроса вдвое или даже больше. Этот момент важен, поскольку конфиденциальность и производительность редко сочетаются друг с другом, поэтому такие улучшения обнадеживают!

Приведенная выше диаграмма также показывает, что в 50% случаев запросы ODoH решаются менее чем за 228 мс. Теперь сравните среднюю линию с левой линией, которая представляет «прямолинейный» (или нормальный) DoH без каких-либо изменений. Эта левая сюжетная линия говорит о том, что в 50% случаев запросы DoH решаются менее чем за 146 мс. Если смотреть ниже отметки 50%, кривые также говорят нам, что ½ времени, в котором разница никогда не превышает 100 мс. С другой стороны, если посмотреть на кривые над отметкой 50%, это говорит о том, что ½ запросов ODoH конкурируют с DoH.

Эти кривые также скрывают много информации, поэтому важно углубиться в измерения. На приведенной ниже диаграмме представлены три различные совокупные кривые распределения, которые описывают производительность ODoH, если мы выбираем прокси и цели по их задержке. Это также пример идей, которые могут выявить измерения, некоторые из которых противоречат здравому смыслу. Например, если смотреть выше 0,5, эти кривые говорят, что ½ времени запроса/ответа ODoH практически неразличимы, независимо от выбора прокси и цели. Теперь переключите внимание ниже 0,5 и сравните две сплошные кривые с пунктирной кривой, которая представляет собой общее среднее значение. Этот регион предполагает, что выбор прокси-сервера с наименьшей задержкой и цели дает минимальное улучшение по сравнению со средним, но, что наиболее важно, он показывает, что выбор прокси с наименьшей задержкой приводит к снижению производительности!

Конечно, остаются открытые вопросы. Этот первый набор измерений был выполнен в основном в Северной Америке. Меняется ли производительность на глобальном уровне? Как это влияет на производительность клиента на практике? Мы работаем над выяснением этого факта, и этот выпуск поможет нам в этом.

Интересно! Могу ли я поэкспериментировать с ODoH? Есть ли открытый сервис ODoH?

Да и да! Мы открыли исходный код наших совместимых реализаций ODoH в Rust, odoh-rs и Go, odoh-go, а также интегрировали цель в Cloudflare DNS Resolver. Правильно, 1.1.1.1 готова принимать запросы через ODoH.

У нас также есть тестовые клиенты с открытым исходным кодом на Rust, odoh-client-rs и Go, odoh-client-go, для демонстрации запросов ODoH. Вы также можете проверить конфигурацию HPKE, используемую ODoH для шифрования сообщений до версии 1.1.1.1, напрямую запросив службу:

$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com 

; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com.	IN	TYPE65

;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300	IN	TYPE65	\# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300	IN	RRSIG	TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==

;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE  rcvd: 291

Мы работаем над добавлением ODoH к существующим преобразователям заглушек, таким как cloudflared. Если вы заинтересованы в добавлении поддержки для клиента или при обнаружении ошибок в реализации, напишите нам по адресу ask-research@cloudflare.com! Объявления о спецификации ODoH и сервере будут отправляться в список рассылки IETF DPRIVE. Вы можете подписаться и следить за объявлениями и обсуждениями спецификации здесь.

Мы намерены продвигать его в IETF и уже наблюдаем интерес со стороны поставщиков клиентов. Эрик Рескорла, технический директор Firefox, говорит:

Oblivious DoH - отличное дополнение к безопасной экосистеме DNS. Мы рады видеть, что он начинает набирать обороты, и с нетерпением ждем возможности поэкспериментировать с ним в Firefox.

Мы надеемся, что к нам присоединятся и другие операторы, которые обеспечат поддержку протокола, запустив прокси-серверы или целевые объекты, и мы надеемся, что поддержка клиентов будет расти по мере увеличения доступной инфраструктуры.

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

Благодарности

Марек Вавруша и Анбанг Вен сыграли важную роль в получении преобразователеи 1.1.1.1 поддержки ODoH. Крис Вуд и Питер Ву помогли подготовить и протестировать библиотеки ODoH. Авторы проекта IETF для ODoH - Эрик Киннер, Патрик Макманус, Томми Поли и Кристофер Вуд. Сам ODoH черпал вдохновение из работы Шмитта и др. "Oblivious DNS: Practical Privacy for DNS Queries" опубликованного в PoPETs 2019.

Перевод статьи:
blog.cloudflare.com