Держите его зашифрованным, держите его в безопасности: работа с ESNI, DoH и DoT

Последние разработки в области защиты конфиденциальности в Интернете включают зашифрованное указание имени сервера TLS (ESNI) и зашифрованный DNS в форме DNS через HTTPS (DoH), оба из которых считаются весьма спорными для сборщиков данных.

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

DNS должен работать правильно

Соединения виртуальной частной сети (VPN) с разделенным туннелем, протокол автоматического обнаружения веб-прокси (WPAD), многоадресный DNS с нулевой конфигурацией (mDNS), черные списки в реальном времени (RBL) и многие другие широко распространенные технологии прерываются, когда DNS не работает. т работать правильно.

Взлом интернета ради прибыли и славы

Еще в 2003 году интернет-пользователи узнали о важности DNS в глобальном масштабе, когда компания, которая тогда управляла доменом верхнего уровня (TLD) .com , решила прекратить выдачу ответов NXDOMAIN . Вместо этого они выдавали себя за любой несуществующий домен, пытаясь показывать больше рекламы, продавать больше доменов и, в конечном итоге, получать больше дохода. Неожиданный эффект домино привел к публичным дебатам и изобличающему отчету Консультативного комитета по безопасности и стабильности (SSAC) ICANN. Этот проект действительно был закрыт, но с технической точки зрения уязвимость сохранилась.

Позднее, в 2008 году, была публично объявлена ​​еще одна попытка манипулирования DNS для получения прибыли, когда некоторые из крупнейших интернет-провайдеров в конечном итоге представили различные способы межсайтовых атак буквально против любого веб-сайта. Из-за характера уязвимостей могут быть использованы даже веб-сайты, размещенные в частной сети и недоступные из Интернета.

Обнаруженная проблема связана не с основными интернет-протоколами, а с проблемой, усугубляемой ненадлежащей монетизацией определенных функций DNS.

Пол Викси, Консорциум интернет-систем (ISC)

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

Взлом Интернета для слежки и цензуры

В 2016 году было замечено, что интернет-провайдеры в Иране манипулируют DNS. На этот раз вместо того, чтобы размещать рекламу, они блокировали доступ к почтовым серверам 139 из 10 000 самых популярных доменов в Интернете. Неясно, является ли это преднамеренной политикой отказа в обслуживании в отношении этих конкретных доменов — аналогично всемирно известной цензуре в Китае — или, возможно, просто примером плохой технической реализации какой-либо системы, перехватывающей DNS-запросы.

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

Однако с технической точки зрения уязвимость сохранилась.

Взлом Интернета в гнусных целях

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

Утечки TLS Кто к кому подключается

Transport Layer Security (TLS) — это технология, лежащая в основе HTTPS, безопасной версии HTTP, на которую мы все полагаемся каждый день. Для установления соединения TLS требуется ряд шагов, в течение которых сервер подтверждает свою личность, предъявляя сертификат, и происходит обмен новыми ключами шифрования.

Использование сервером сертификата для подтверждения своей личности является очень важным шагом, поскольку частью сертификата является асимметричный открытый ключ шифрования.

Когда клиент отправляет сообщение с использованием этого ключа, только сервер, который владеет соответствующим закрытым ключом, может прочитать сообщение. В результате любой, кто перехватывает или прослушивает соединение, блокируется и не может прочитать содержимое.

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

Выделение домена

Несколько инструментов антицензурного типа какое-то время обходили эту утечку в TLS, используя технику, известную как выделение домена. Это использует тот факт, что после установления HTTPS-соединения большинство крупных хостинг-провайдеров не проверяют, соответствует ли имя хоста, представленное в каждом HTTP-запросе, имени, используемому в рукопожатии TLS. С точки зрения инструментов конфиденциальности, это считалось полезной функцией, позволяющей тайно связываться со скрытым сайтом. Хостинг-провайдеры и сборщики данных расценили это как злоупотребление способом реализации спецификации.

Это само по себе уязвимость, и поэтому она была исправлена ​​несколькими крупными хостинг-провайдерами, включая AWS.

Решение проблемы путем изменения стандарта: зашифрованный SNI (ESNI)

Идея ESNI состоит в том, чтобы предотвратить утечку данных TLS путем шифрования всех сообщений, включая исходное сообщение Client Hello . Это оставляет любого наблюдателя в полном неведении относительно того, какой сертификат сервера представляет сервер.

Для этого клиенту необходим ключ шифрования перед подключением. Поэтому ESNI требует, чтобы определенный набор ключей шифрования ESNI был помещен в запись SRV в DNS.

Однако точные детали этого еще не определены, поскольку спецификация еще не завершена. Несмотря на это, реализация ESNI уже запущена в производство Mozilla Firefox и Cloudflare.

Защита и шифрование DNS

Чтобы ключи ESNI доставлялись без перехвата, важно защититься от подделки DNS.

Еще с 1993 года интернет-сообщество пыталось защитить DNS. IETF отмечает, что на ранних собраниях по решению проблем обсуждались:

1. Защита от раскрытия данных DNS неуполномоченным лицам
2. Обеспечение целостности данных
3. Аутентификация источника данных

Результатом этих совещаний стал стандарт расширений безопасности системы доменных имен (DNSSEC) в 1997 году. Стандарт решил решить две из трех проблем, поскольку группа разработчиков приняла явное решение исключить все угрозы раскрытия данных за пределы области действия.

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

К сожалению, поскольку он полностью обратно совместим с «небезопасным DNS» и довольно сложно правильно реализовать, внедрение DNSSEC очень низкое. Многие владельцы доменов сдаются на полпути, пытаясь настроить его, о чем свидетельствуют многочисленные недействительные и наполовину настроенные конфигурации, встречающиеся в дикой природе.

DNS через HTTPS (DoH)

Чтобы ключи ESNI доставлялись так, чтобы наблюдатели не знали, какой сайт пытаются посетить пользователи, важно защититься от прослушивания DNS. Таким образом, вполне логично и понятно сказать, что зашифрованный DNS (например, с DoH) — это хорошо. Тем не менее, в настоящее время DNS не зашифрован.

Mozilla, Google, APNIC, Cloudflare, Microsoft и другие предпринимают шаги, чтобы изменить это.

Идеальный зашифрованный пользовательский опыт

Пользователь, желающий использовать вышеперечисленные технологии, может иметь довольно длинный список требований, когда дело доходит до практических деталей UX при работе с шифрованием. Скорее всего, они хотели бы избежать таких вещей, как:

• Принуждение к использованию определенного поставщика услуг DNS (независимо от того, насколько он хорош) или для того, чтобы выбор был невидимым или трудным для поиска
• Каждое приложение на устройстве обрабатывает DNS по-разному (например, Firefox может находить то, чего не может Safari).
• Все приложения на устройстве должны создавать собственную безопасную реализацию DNS внутри себя.
• Необходимость вручную настраивать DNS несколько раз
• Необходимость выбрать конфиденциальность и безопасность
• Приложения возвращаются к небезопасной работе без согласия пользователя

Вместо этого пользователи, заботящиеся о конфиденциальности, хотели бы:

• Конфиденциальность от несанкционированного наблюдения со стороны кого бы то ни было
• Защита от таргетированной рекламы, на которую они не давали согласия
• Защита собственного опубликованного контента (например, на личном веб-сайте) от изменения или манипулирования на пути к другим зрителям.
• Гарантия того, что зрители собственного опубликованного контента не столкнутся с проблемами просто из-за доступа к нему.
• Чтобы по-прежнему иметь возможность контролировать DNS в своих собственных сетях (поскольку иногда DNS с «расщепленным горизонтом» хорош для того, чтобы внутренние ресурсы были ограничены внутренними пользователями).
• Возможность включить или, по крайней мере, отказаться от фильтрации на уровне DNS (например, Quad9, CleanBrowsing и OpenDNS Family Shield)
• Простая и простая настройка (например, DHCP)
• Попросить дать согласие на использование DNS без шифрования
• Защита не только трафика браузера, но и всех типов трафика, например, электронной почты, Slack, VoIP, SSH, VPN и т. д.

Текущие усилия по шифрованию

Какие варианты есть для пользователей с вышеуказанными целями?

Решение Mozilla — это начало, но далеко не идеальное. Они защищают только Firefox; по умолчанию настройки вашей ОС переопределяются в пользу их выбора провайдера (Cloudflare), не говоря об этом, и он молча возвращается к небезопасности (в случаях блокировки зашифрованного DNS и т. д.)

Решение Google является лучшим подходом. Они защищают Android 9+, что относится ко всем приложениям. (Я не уверен в их планах в отношении Chrome OS, но я подозреваю, что они находятся в разработке.) Они также защищают Chrome на всех платформах, но это срабатывает только тогда, когда хост-платформа настроена на использование провайдера, поддерживающего безопасность. Это хорошо с точки зрения пользовательского выбора, но не идеально, потому что автоматически становится небезопасным.

Все остальные основные браузеры также реализуют поддержку.

В идеальной ситуации для пользователей более широкое сообщество разработчиков программного обеспечения и ОС должно:

1. Прекратите внедрять новые функции безопасности DNS на уровне приложений.
2. Начните внедрять их на уровне ОС
3. Уважайте конфигурацию на уровне ОС или получите согласие пользователя

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

Linux и BSD уже имеют эту функциональность с множеством доступных опций. К сожалению, насколько я знаю, ни один из дистрибутивов не включает ни один из них по умолчанию. Проверьте nss-tls, если вам нужно что-то, что просто подключается к glibc.

Реализация Google DNS-over-TLS в Android 9+ уже делает это. Он работает, проверяя DNS-сервер на поддержку шифрования. Если он у него есть, то он будет его использовать. Если это не так, то, как и в случае с Chrome, он продолжает работать небезопасным образом, не запрашивая согласия.

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

На момент написания этой статьи поддержка зашифрованного DNS для устройств Apple и Microsoft еще официально не появилась. Поскольку в ноябре 2019 года Microsoft объявила о своих намерениях поддерживать зашифрованный DNS, мы надеемся, что Apple вскоре последует этому примеру.

Обходные пути зашифрованного DNS

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

Вдохновением для написания этой статьи послужил прокси-сервер DNSCrypt, который очень стабилен, имеет множество наворотов и является кроссплатформенным. Он поддерживает старый протокол DNSCrypt, а также новые протоколы DNS через TLS (DoT) и DNS через HTTPS (DoH).

Для пользователей Windows есть установщик и графический интерфейс под названием Simple DNSCrypt, который является полным и очень простым в использовании.

Я рекомендую его, но имейте в виду, что мир, вероятно, еще не готов для вас, и вам может понадобиться время от времени отключать его (например, когда вам нужно использовать портал захвата в вашем любимом кафе или в локальной сети). партия).

Другие варианты

Кроме того, существует DNS-сервер Technitium, который поддерживает зашифрованный DNS, является кроссплатформенным (Windows, MacOS, Linux на ARM/Raspberry Pi) и имеет удобный веб-интерфейс. Он находится в разделе «другое», потому что это скорее универсальный инструмент, чем решение, специфичное для этой проблемы. (Это, вероятно, будет хорошим выбором, если вы хотите запустить свой DNS-сервер Raspberry Pi дома. Мне было бы интересно услышать отзывы людей, которые попробовали это, в комментариях ниже.)

Для ваших устройств Android или iOS (iPhone, iPad и т. д.) также есть приложение 1.1.1.1, которое будет принудительно передавать все ваши DNS-запросы через службу Cloudflare Encrypted DNS. Я слышал, что есть и более гибкие приложения, такие как Intra, но я еще не тратил время на их тестирование.

Конечно, вы также можете включить зашифрованный DNS как в Firefox, так и в Chrome — просто имейте в виду все предостережения, описанные выше.

Надежность DNS: задача номер один

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