Хабрахабр

[Перевод] Как спрятать DNS-запросы от любопытных глаз провайдера

Настройка 1.1.1.1 от Cloudflare и других DNS-сервисов по-прежнему требует навыков работы в командной строке


Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес

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

Например, он превращает arstechnica.com в 50. DNS — это телефонный справочник Сети, выдающий фактический сетевой адрес IP, связанный с хостингом и доменными именами сайтов и других интернет-служб. 169. 31. Ваш интернет-провайдер предлагает DNS в пакете услуг, но он также может журналировать DNS-трафик — по сути, записывать историю ваших действий в интернете. 131.

1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. «Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.
Названный по своему IP-адресу, сервис 1. 1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. 1. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.

1. Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1. 1 — никак не первый DNS-сервис с шифрованием. 1. 8. Успешно работают Quad9, OpenDNS от Cisco, сервис 8. 8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. 8. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.

Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1. Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. 0. 0. 1. 0/24 и 1. 0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. 1. Но APNIC не получит доступ к зашифрованному трафику DNS.

В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. И не все сервисы одинаковы с точки зрения софта и производительности.

В итоге моя внутренняя лабораторная крыса победила — и я обнаружил, что тестирую и разбираю клиенты для нескольких провайдеров DNS через три протокола DNS-шифрования: DNSCrypt, DNS по TLS и DNS по HTTPS. Но учитывая важность вопроса — в последнее время во всех новостях говорят о превращении пользовательских данных в продукт — я решил посмотреть, как работает DNS-шифрование у Cloudflare. Все они работоспособны, но предупреждаю: хотя процедура становится проще, но вряд ли вы сможете объяснить шифрование DNS родителям по телефону (если только они не опытные пользователи командной строки Linux).


Как работает DNS

Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.


Как выглядит типичный обмен данными между устройством и DNS-резолвером

Но есть проблема с суррогатами резолверов на различных операционных системах. «У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Проблема особенно заметна в странах, где власти более враждебно относятся к интернету. В реальности мы не можем их защитить».

Но это всё равно не мешает злоумышленнику фильтровать запросы по контенту или перехватывать адреса методом пакетного перехвата или глубокой инспекции пакетов. В некоторой степени помогает использование DNS, который не ведёт логи. Что-то подобное (хотя, по-видимому, не злонамеренно), похоже, происходит со случайным перенаправлением трафика на адрес 1. Кроме пассивной прослушки есть угроза более активных атак на ваш DNS-трафик — спуфинг DNS-сервера со стороны провайдера или спецслужб с перенаправлением на собственный сервер для отслеживания или блокировки трафика. 1. 1. 1 из сети AT&T, судя по сообщениям на форумах DSLReports.

Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. Наиболее очевидный способ уклонения от слежки — использование VPN. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.

Шифрование гарантирует, что трафик не просканируют и не изменят, и что запросы не получит и не обработает поддельный DNS-сервер. Вот где вступают в игру протоколы шифрования DNS: это DNSCrypt (среди прочих, его поддерживает OpenDNS от Cisco), DNS по TLS (поддерживается Сloudflare, Google, Quad9, OpenDNS) и DNS по HTTPS (поддерживается Сloudflare, Google и сервисом блокировки «взрослого» контента CleanBrowsing). DNS-прокси с одной из этих служб (непосредственно на устройстве или на «сервере» в локальной сети) поможет предотвратить DNS-утечки через VPN, поскольку прокси-сервер всегда будет самым быстрым DNS-сервером среди всех доступных. Это защищает от атак MiTM и шпионажа.

Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Однако эта опция защиты недоступна массовому пользователю. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору.

Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера.


Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows

Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.

Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. «DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.

Сделать это очень дёшево и легко. «DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».

Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Есть версии для Windows, MacOS, BSD и Android.

Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Но для начала работы достаточно самой базовой конфигурации. Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.

Затем подключается к серверу с самым быстрым откликом. По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Информация о серверах в списке кодируется как «штамп сервера». При необходимости можно изменить конфигурацию и выбрать конкретный сервис. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате). Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены.

При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. В целом, я не заметил замедления скорости при просмотре веб-страниц.

Хорошо это или плохо, но он передаёт UDP-трафик по порту 443 — тот же порт используется для безопасных веб-соединений. Основное преимущество DNSCrypt в том, что он похож на «обычный» DNS. Чтобы ещё больше снизить вероятность блокировки, можно изменить конфигурацию клиента и передавать запросы по TCP/IP (как показало тестирование, это минимально влияет на время отклика). Это даёт относительно быстрый резолвинг адресов и снижает вероятность блокировки на файрволе провайдера. Так шифрованный DNS-трафик для большинства сетевых фильтров похож на трафик HTTPS — по крайней мере, с виду.

Снифер Wireshark говорит, что это трафик HTTPS, потому что я форсировал использование TCP.
Показан трафик DNSCrypt и локальный трафик DNSCrypt Proxy. Если пустить его по UDP, то Wireshark увидит трафик Chrome QUIC

Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Такая схема не используется в DNSCrypt 2.

«DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. С точки зрения разработчика немного сложно работать с DNSCrypt. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.

Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис. Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках.

Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».

Сейчас DNSCrypt Proxy поддерживает DNS по HTTPS и указывает Cloudflare, Google и Quad9 в настройках по умолчанию. Хотя несколько DNS-сервисов используют DNSCrypt (например, CleanBrowsing для блокировки «взрослого» контента и Cisco OpenDNS для блокировки вредоносных доменов), новые ориентированные на приватность DNS-провайдеры (в том числе Google, Cloudflare и Quad9) отказались от DNSCrypt и выбрали одну из других, одобренных группой IETF технологий: DNS по TLS и DNS по HTTPS.


TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки

У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.

Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Существует несколько рабочих клиентов для DNS по TLS. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.

Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Он также написал shell скрипт для установки на Raspberry Pi.

Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Сначала я использовал табы — и всё поломал. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare).

SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:

upstream_recursive_servers:
#IPv4
#Cloudflare DNS over TLS server - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
- address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.

0. После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127. 1 (localhost). 0. Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.


Переключаемся с обычного трафика DNS на шифрование TLS

Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс. Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности.

Обычно DNS работает по быстрому протоколу UDP: отправил и забыл, в то время как сообщение TCP требует согласования соединения и проверки получения пакета. Частично замедление работы происходит на стороне сервера из-за лишнего использования TCP. Основанная на UDP версия DNS по TLS под названием DNS over Datagram Transport Layer Security (DTLS) сейчас в экспериментальной разработке — она может увеличить производительность протокола.

Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Здесь тоже имеется проблема с управлением сертификатами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами.

Он проходит через большинство файрволов, словно тех не существует. Но это не проблема для лидера нашего хит-парада — DNS по HTTPS.


Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS

И Google, и Cloudflare, кажется, видят протокол DNS по HTTPS, также известный как DoH, как самый перспективный вариант для шифрования DNS. Опубликованный в виде черновика стандарта IETF, протокол DoH инкапсулирует DNS-запросы в пакеты HTTPS, превращения их в обычный зашифрованный веб-трафик.

И здесь нет никаких проблем с управлением сертификатами. Запросы отправляются как HTTP POST или GET с телом в формате сообщения DNS (датаграммы из обычных DNS-запросов) или как запрос HTTP GET в формате JSON (если вы не против небольшого оверхеда). Как и при обычном веб-трафике HTTPS, для подключения через DoH не требуется аутентификация, а сертификат проверяется центром сертификации.

Видно только HTTPS, TLS и ничего больше
Фиксация DNS-транзакции через DoH.

Необходимые ресурсы на стороне сервера почти наверняка заставят прослезиться администратора обычного DNS-сервера. HTTPS — довольно громоздкий протокол для запросов DNS, особенно в формате JSON, поэтому придётся смириться с некоторым снижением производительности. Но простота работы с хорошо понятными веб-протоколами делает разработку как клиентского, так и серверного кода для DoH намного более доступной для разработчиков, собаку съевших на веб-приложениях (всего несколько недель назад инженеры Facebook выпустили концепт сервера и клиента DoH на Python).

Правда, некоторые из них заточены под конкретных провайдеров DNS. В результате, хотя на спецификациях RFC для DoH ещё не просохли чернила, уже готов к работе целый ряд клиентов DNS по HTTPS. Потеря производительности во многом зависит от сервера и от качества конкретного клиента.

Это многофункциональный инструмент туннелирования, предназначенный в первую очередь для установления безопасного канала для связи веб-серверов с CDN-сетью Cloudflare. Например, возьмём клиент туннелирования Argo от Cloudflare (aka cloudflared). DNS по HTTPS — просто ещё одна служба, которую теперь поддерживает CDN.

Если не настроен обычный DNS, то возможна небольшая проблемка, потому что данный адрес должен резолвиться в 1. По умолчанию, если запустить Argo из командной строки (в Linux и MacOS для этого нужны привилегии суперпользователя, а на Windows нужно запускать клиента из PowerShell от имени администратора), то он направляет DNS-запросы на https://cloudflare-dns.com/dns-query. 1. 1. 1, иначе Argo не запустится.

Первый вариант: установить устройство с локальным хостом (127. Это можно исправить одним из трёх способов. 0. 0. 1. 1 для IPv4 и ::1 для IPv6) как основной DNS-сервер в сетевой конфигурации, а затем добавить 1. 1 в качестве дополнительного резолвера. 1. Лучше добавить URL сервера из командной строки при загрузке: Это рабочий вариант, но он не идеален с точки зрения приватности и производительности.

$ sudo cloudflared proxy-dns --upstream https://1.0.0.1/dns-query

Если вы уверены, что хотите перейти на DNS-сервер от Cloudflare, что даёт преимущество автоматического обновления, — то можете настроить его в качестве службы в Linux, используя YAML-файл конфигурации, содержащий адреса IPv4 и IPv6 службы DNS от Cloudflare:

proxy-dns: true
proxy-dns-upstream:
- https://1.1.1.1/dns-query
- https://1.0.0.1/dns-query

При настройке с правильной восходящей адресацией производительность dig-запросов через Argo широко варьируется: от 12 мс для популярных доменов аж до 131 мс. Страницы с большим количеством межсайтового контента загружаются… немного дольше обычного. Опять же, ваш результат может быть другим — вероятно, он зависит от вашего местоположения и связности. Но это примерно то, чего я ожидал от мрачного протокол DoH.


Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек

Во-первых, прокси-сервер от Google под названием Dingo. Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Запросы dig в среднем выполнялись более 100 миллисекунд. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS.

8. Во время проверки обработки стандартных запросов службой dns.google.com я наткнулся на альтернативу дефолтному адресу 8. 8 от Google (172. 8. 8. 217. Я добавил его в Dingo из командной строки: 14, если знаете).

$ sudo ./dingo-linux-amd64 -port=53 -gdns:server=172.216.8.14

Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.

После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.

С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. Это показатель без оптимизации на ближайший DNS-сервер от Google.

На самом деле он даже быстрее. В целом производительность DNSCrypt Proxy по DoH практически неотличима от резолвера DNS по TLS, который я проверял ранее. Я не уверен, то ли это из-за какой-то особой реализации DoH — может быть, из-за использования стандартного формата сообщений DNS, инкапсулированных в HTTPS, вместо формата JSON — то ли связано с тем, как Cloudflare обрабатывает два разных протокола.


Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей

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

Если на сервере хостятся несколько сайтов, то расширение TLS под названием Server Name Indicator (SNI), используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта, на который вы зашли. Тем не менее, важно отметить, что одно лишь шифрование DNS не скроет ваши действия в интернете. Но ни один из перечисленных сервисов не работает с Tor. Для полной конфиденциальности всё равно нужно использовать VPN (или Tor) для такой инкапсуляции трафика, чтобы провайдер или какая-либо другая шпионящая сторона не могла вытянуть метаданные из пакетов. И если против вас работает правительственное агентство, то ни в чём нельзя быть уверенным.

Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.

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

Надеюсь, сообщество вокруг DNSCrypt продолжит свою активность и продвинет ситуацию вперёд. Так что в ближайшее время эти протоколы останутся инструментом для тех немногих людей, кто реально заботится о конфиденциальности своих данных и готов для этого немного потрудиться.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть