Главная » Хабрахабр » [Перевод] DoH в картинках

[Перевод] DoH в картинках

Угрозы конфиденциальности и безопасности в интернете становятся серьёзнее. Мы в Mozilla внимательно их отслеживаем. Считаем своей обязанностью сделать всё возможное для защиты пользователей Firefox и их данных.

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

Сейчас мы добавляем в список ещё две технологии:

  • DNS по HTTPS — новый стандарт IETF, в разработке которого мы приняли участие
  • Trusted Recursive Resolver — новый безопасный способ резолвить DNS, предоставляется совместно с Cloudflare

Благодаря двум этим инициативам устраняются утечки данных, которые являлись частью системы доменных имен с момента её создания 35 лет назад. И нам нужна ваша помощь в тестировании. Давайте посмотрим, как DNS по HTTPS и Trusted Recursive Resolver защищают наших пользователей.

Но сначала посмотрим, как веб-страницы передаются по интернету.

Если вы уже знаете, как работают протоколы DNS и HTTPS, можете перейти к разделу о том, как помогает DNS по HTTPS.

Когда люди объясняют, как браузер загружает веб-страницу, то обычно объясняют это так:

  1. Ваш браузер делает запрос GET на сервер.
  2. Сервер отправляет ответ, который представляет собой файл, содержащий HTML.

Эта система называется HTTP.

Ваш браузер не разговаривает напрямую с сервером. Но эта схема слишком упрощена. Наверное потому что они не близки друг другу.

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

То же самое верно для ответа. Таким образом, прежде чем запрос попадёт из браузера на сервер, он пройдёт через несколько рук.

Снаружи в записке написано, кому она предназначена. Я думаю об этом как о школьниках, передающих друг другу записки в классе. Затем тот следующий ребёнок передаёт её одному из соседей — вероятно, не конечному получателю, а тому, кто находится в нужном направлении. Ребёнок, написавший записку, передаст её соседу.


— Псст… передай это Сэнди

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

Она может оказаться в руках людей, которые сделают вредные вещи…

Например, поделятся содержанием записки со всеми.

Эй народ!
— О, это пикантно…. Дэнни влюбился в Сэнди!

Или изменят ответ.


— Я тебе тоже нравлюсь?
— Хе-хе, подшучу над ним и напишу «Нет»...

Она называется HTTPS: это словно замок на каждом сообщении. Чтобы устранить эти проблемы, создана новая безопасная версия HTTP.

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

Но между вашим браузером и сервером всё еще есть незашифрованные сообщения. Это решает многие вопросы безопасности. Значит, люди на пути всё ещё могут вмешиваться в ваши дела.

При отправке исходного сообщения на сервер вы также отправляете имя сервера в поле “Server Name Indication”. Например, данные по-прежнему открыты во время установки подключения. Этот первоначальный запрос — часть установки шифросвязи, но сам первоначальный запрос не шифруется. Это позволяет операторам сервера запускать несколько сайтов на одном компьютере и в то же время понимать, с кем вы хотите связаться.

Но что такое DNS? Другое место, где данные открыты — это DNS.

В метафоре с передачей записок в классе я сказала, что имя получателя должно быть написано снаружи записки. Это верно и для HTTP-запросов… они должны объявить, куда собираются идти.

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

80.
— Пожалуйста, отправь это на 208. 224 154.

Пользователям неудобно запоминать цифры IP-адреса. Это вызывает проблемы. Хочется дать сайту запоминающееся имя… которое отложится в памяти у людей.

Ваш браузер использует DNS для преобразования имени сайта в IP-адрес. Вот почему у нас есть система доменных имен (DNS). Этот процесс — преобразование доменного имени в IP-адрес — называется разрешением имени домена или резолвингом.

Как браузер решает задачу?

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

Это позволяет им управляться независимо. Таким образом, вместо одного списка для всех доменных имён существует много небольших списков, связанных друг с другом.

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

Как выглядит такой поиск клада для сайта вроде англоязычной Википедии, en.wikipedia.org?

Домен можно разделить на части.

Но нам нужна помощь в поисках. С такими частями можно начать охоту на список, содержащий IP-адрес сайта. Инструмент, который осуществляет эту охоту вместо нас и находит IP-адрес, называется резолвером.

Он знает несколько различных корневых DNS-серверов, поэтому отправляет запрос одному из них. Сначала резолвер обращается к так называемому корневому DNS-серверу. Резолвер спрашивает корневой DNS, где найти дополнительные сведения об адресах в доменной зоне верхнего уровня .org.

6.
— Вы не знаете, как пройти на en.wikipedia.org?
— Я не знаю ни о чём в зоне .org, но 5. 8 может помочь
7.

Сервер TLD знает обо всех доменах второго уровня, которые заканчиваются на .org. Следующий сервер называется сервером имён домена верхнего уровня (TLD).

Впрочем, он ничего не знает о поддоменах wikipedia.org, поэтому тоже не знает IP-адрес en.wikipedia.org.

Сервер имён TLD посоветует резолверу задать этот вопрос серверу имён Википедии.

21.
— Вы не знаете, как пройти на en.wikipedia.org?
— Иди и спроси у 11. 41, он знает о сайтах в домене wikipedia.org
31.

Сервер имён Википедии — это то, что называется авторитативный сервер. Резолвер почти закончил. Таким образом, он знает и о en.wikipedia.org, и об остальных поддоменах, такие как немецкая версия de.wikipedia.org. Он знает обо всех поддоменах wikipedia.org. Авторитативный сервер сообщает резолверу, по какому IP-адресу можно получить HTML-файлы для этого сайта.

80.
— Вы не знаете, как пройти на en.wikipedia.org?
— О да, просто иди на 208. 224
154.

Резолвер вернёт операционной системе IP-адрес en.wikipedia.org.

Этот процесс называется рекурсивным разрешением, потому что приходится ходить туда и обратно, задавая разным серверам по сути один и тот же вопрос.

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

Можешь помочь?
— Конечно, позволь познакомить тебя с резолвером, который я использую
— Мне нужен резолвер.

Существует два возможных способа. Как операционная система знает, какой резолвер использовать?

Но очень немногие люди делают это. Вы можете настроить компьютер на использование определённого резолвера, которому доверяете.

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

А если тебе понадобится резолвер, рекомендую вот этот
— Можно мне получить IP-адрес?
— Без проблем!

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

Так как эта система подвергает опасности пользователей?

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


Содержит большую часть вашего IP-адреса…
… и полный домен, который вы ищете

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

Два основных — трекинг (отслеживание) и спуфинг (подмена). Существует несколько способов, как подобная система подвергает риску данные пользователей.

Трекинг

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

Многие люди и компании готовы немало заплатить, чтобы увидеть вашу историю посещённых страниц. И это ценные данные.


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

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

Как я уже упоминала, каждый раз в кафе, отеле или в любой другой сети вам, вероятно, дадут другой резолвер. Даже если вы доверяете рекомендованному резолверу от сети, то вероятно используете его только дома. И кто знает, какова его политика сбора данных?

Кроме того, что ваши данные собираются и затем продаются без вашего ведома или согласия, систему используют ещё более опасным способом.

Спуфинг

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

6.
Отправь это на 1. 6… это абсолютно правильный адрес, а вовсе не поддельный сайт, который я контролирую 6.

Опять же, здесь и сам резолвер может действовать гнусно.

Вы хотите сравнить цены и посмотреть, не продаётся ли такой товар дешевле в конкурирующем интернет-магазине big-box.com. Предположим, вы делаете покупку в магазине Megastore.

Он может перехватить запрос к big-box.com и соврать вам, что сайт недоступен. Но если вы пользуетесь Megastore WiFi у них в торговом зале, то вероятно используете их резолвер.

Мы в Mozilla твёрдо убеждены, что несём ответственность за защиту пользователей и их данных, и поэтому работаем над устранением данных уязвимостей.

Потому что на самом деле имеется три угрозы: Представляем две новые функции для исправления ситуации: это доверенный рекурсивный резолвер (Trusted Recursive Resolver, TRR) и DNS по HTTPS (DoH).

  1. Вы можете в конечном итоге использовать ненадёжный резолвер, который отслеживает ваши запросы или подменяет ответы от DNS-серверов.
  2. Маршрутизаторы по пути могут отслеживать запросы или вмешиваться таким же образом.
  3. DNS-серверы могут отслеживать DNS-запросы.

Как этого избежать?

  1. Избегать ненадёжных резолверов с помощью TRR.
  2. Защищаться от прослушивания и спуфинга с помощью DNS по HTTPS.
  3. Передавать как можно меньше данных, чтобы защитить пользователей от деанонимизации.

Избегать ненадёжных резолверов с помощью TRR

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

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

Мы долго искали компанию, которая поможет нам защитить DNS-данные пользователей. Тем не менее, мы изучили этих риски… и у нас есть определённое влияние. И нашли одну такую: Cloudflare.

Они обязались удалять все привязанные к конкретным людям данные (personally identifiable data) после 24 часов и никогда не передавать эти данные третьим лицам. Cloudflare предоставляет сервис рекурсивного резолвинга с политикой конфиденциальности для пользователей. Будут проводиться регулярные проверки, что данные действительно удаляются, как было обещано.

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

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

Пользователи могут настроить Firefox на использование любого рекурсивного резолвера с поддержкой DoH. Но это не значит, что вы должны использовать Cloudflare. По мере появления новых сервисов мы планируем реализовать простое обнаружение и переключение между ними.

Защищаться от прослушивания и спуфинга с помощью DNS по HTTPS

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

Использование HTTPS для обмена DNS-пакетами защищает DNS-запросы наших пользователей от шпионажа.

Передавать как можно меньше данных, чтобы защитить пользователей от деанонимизации

Вдобавок к доверенному резолверу, который работает по протоколу DoH, мы с компанией Cloudflare работаем над дополнительными мерами безопасности.

Но сервер Cloudflare будет поступать иначе. Обычно резолвер отправляет полное имя домена каждому серверу: корневому DNS, серверу имён доменов верхнего уровня, второго уровня и т. д. Это называется минимизация QNAME. Он будет отправлять только ту часть, которая имеет отношение к конкретному DNS-серверу.


— Вы не знаете, как пройти на сервер .org?

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

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

Всё это — удаление ненужных частей домена и IP-адреса — означает, что DNS-сервер может собрать о вас гораздо меньше данных.

Эти защитные меры сокращают количество людей, которые могут видеть историю посещённых вами страниц. Но они полностью не исключают утечки данных.

Для этого необходимо отправить запрос. После выполнения поиска в DNS для получения IP-адреса по-прежнему необходимо подключиться к веб-серверу по этому адресу. И этот запрос не шифруется. Запрос включает в себя SNI (server name indication) с указанием конкретного сайта на сервере.

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

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

Когда вы открываете соединение с совместимым сервером, он сообщит, какие ещё сайты размещаются на нём. Это иногда называют слиянием соединения HTTP/2 (connection coalescing) или просто повторным использованием соединения. Затем вы можете посетить эти сайты, используя существующее зашифрованное соединение.

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

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

Уже сейчас в Firefox вы можете включить DNS по HTTPS, и мы рекомендуем сделать это.

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

Поэтому мы проводим исследование. Но это значительное изменение, и его нужно сначала протестировать. Половину наших пользователей Firefox Nightly мы просим помочь собрать данные о производительности.

Затем мы сравниваем результат для проверки, что всё работает как положено. В тестировании используется резолвер по умолчанию, как и сейчас, но также запросы отправляются на DoH-резолвер Cloudflare.

Мы просто проверяем, что всё работает, а затем выбрасываем ответ Cloudflare. Для участников исследования ответ Cloudflare DNS пока не используется.

Надеемся, что вы тоже поможете нам. Выражаем благодарность за поддержку пользователям Nightly, которые каждый день помогают тестировать Firefox.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

«Противостояние» на PHDays 8 — взгляд со стороны SOC

В мае этого года прошла конференция Positive Hack Days 8, на которой мы вновь поучаствовали в роли SOC в уже традиционном Противостоянии (The Standoff). Атакующие — молодцы! В этом году организаторы учли прошлые ошибки и Противостояние началось в срок. Нападали ...

Погружение в AD: разбираем продвинутые атаки на Microsoft Active Directory и способы их детекта

Изображение: Pexels Участники рассказывают о новых векторах и своих изобретениях, но не забывают и о советах, как можно их обнаружить и предотвратить. За последние четыре года ни один Black Hat или DEF CON не обошелся без докладов на тему атак ...