dxdt.ru: занимательный интернет-журнал

Очень много сообщений про DNS-over-HTTPS в Firefox, про то, что внедрение этого протокола, якобы, “позволяет обходить любые блокировки и DPI”. Между тем, DNS-over-HTTPS (DoH) в Firefox – это способ сокрытия DNS-запросов и DNS-ответов от третьей стороны, причём скрываются только запросы от браузера до рекурсивного резолвера (подразумевается, что до резолвера Cloudflare). Заметьте, что использование DoH не скрывает рекурсивные запросы, источником которых является браузер Firefox. Например, если некоторую уникальную DNS-метку встроить в веб-страницу, то на авторитативном сервере будет видно, откуда пришёл рекурсивный запрос, соответствующий конкретной сессии конкретного браузера. По IP-адресу источника запроса (рекурсивного резолвера), по некоторым другим признакам, можно определить, используется ли клиентом штатный DNS от провайдера доступа, или это та или иная реализация DoH. В качестве источника DNS-меток (такой источник принято называть “праймером”) с большим охватом может работать любой популярный веб-сервис или веб-сайт: например, какой-нибудь веб-счётчик (что-то подобное “Яндекс.Метрике”), страница популярной социальной сети и т.д.

Однако на пути от браузера до рекурсивного резолвера, действительно, запросы и ответы DNS не будут видны третьей стороне, просматривающей трафик, так как они в HTTPS защищены шифрованием. Но к “обходу блокировок” это относится весьма косвенно.

Предположим, что блокировка доступа к веб-ресурсу осуществляется провайдером на уровне DNS. Смысл подобного метода блокирования в том, чтобы браузер (или другие программы-клиенты) не мог определить подлинный IP-адрес, с которым требуется установить соединение. Как такая блокировка работает?

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

В продвинутом варианте, уже система DPI обнаруживает все DNS-запросы и DNS-ответы, вне зависимости от того, к каким DNS-серверам они отправлены и от каких получены. Фильтрующий узел вмешивается в трафик в том случае, если силами DPI обнаружены запросы, относящиеся к заблокированным именам. Вмешательство в трафик может выражаться как в подмене ответов, так и в блокировании запросов; конечно, можно заблокировать и ответы. В этом случае DoH помогает, так как DPI перестаёт видеть DNS-трафик. Однако тот же фильтрующий узел и DPI можно настроить так, что они будут блокировать трафик DoH. Блокировать придётся весь трафик, а DPI потребуется очень серьёзно доработать. При этом в Firefox по умолчанию будут встроены средства, позволяющие предотвратить автоматическое включение использования DoH. Эти средства предназначены для корпоративных сетевых сред, где фильтрация DNS нередко является обязательным требованием “политик безопасности”. Такое поведение браузера пользователь может преодолеть, если включит использование DoH вручную.

(Отмечу, в скобках, что все описанные выше методы с подменой информации DNS противоречат DNSSEC и, соответственно, будут обнаружены, если клиент поддерживает DNSSEC.)

Защита от просмотра DNS-трафика никак не влияет на блокировку доступа непосредственно по IP-адресу узла: если соединение с конкретным адресом установить не удаётся, то не важно, как этот адрес был получен – через “открытый DNS” провайдера или через “защищённый DNS-over-HTTPS”. Да, нетрудно предложить вариант, в котором IP-адреса постоянно изменяются, а “верный адрес” передаётся только при использовании сервиса DoH. Так можно устроить, если авторитативные серверы DNS соответствующей доменной зоны как-то связаны с провайдером сервиса DoH. Однако при этом активная система блокирования может узнавать “верные адреса”, просто используя свой экземпляр браузера Firefox. Конечно, всегда остаётся экстенсивный вариант развития данной схемы, при котором, с одной стороны, сотни тысяч IP-адресов случайно распределяются по DNS-ответам, а с другой стороны – какие-то, – возможно те же, – сотни тысяч и миллионы адресов попадают под превентивную блокировку. При этом DoH здесь помогает только тем сервисам, у которых очень много IP-адресов.

Нередко можно услышать, что данный метод, применительно к проблеме блокирования доступа, хорош тем, что его трафик, по внешним признакам, не отличается от “обычного HTTPS” (то есть, от HTTPS для веб-сайта). Мало кто готов блокировать весь HTTPS-трафик. Конечно, приложив достаточно вычислительных мощностей, попытаться отличить трафик DoH от работы с веб-сайтами – можно: есть IP-адреса, есть характеристики отправляемых и принимаемых пакетов, продвинутая система блокирования умеет делать проверку сервисов (connection probe) и так далее. Другое дело, что ресурсов для блокирования потребуется действительно много и будут ложные срабатывания. Более того, в качестве следующего шага по защите возможно заворачивание DNS-трафика в “самый настоящий” HTTPS-сеанс работы с обычным веб-сайтом: DNS-запросы могут передаваться браузером в качестве нагрузки, в специальных HTTP-заголовках; и в таких же HTTP-заголовках сервер пришлёт ответы.

В целом, сверхидея DNS-over-HTTPS хорошо укладывается в самую современную концепцию в области информационной безопасности. В этой концепции “доверенными” являются только приложения – клиентское и серверное. То есть, даже операционная система не относится к доверенным. Криптография позволяет двум приложениям надёжно идентифицировать (и аутентифицировать) друг друга: браузер Firefox, используя принесённые с собой TLS-сертификаты, идентифицирует и аутентифицирует серверное приложение, которое исполняется на узлах Cloudflare и реализует сервис рекурсивного опроса доменных имён. Для схемы не важно, каким образом, по каким транзитным сетям, приложения устанавливают между собой соединение. Да, тут есть масса оговорок – про аппаратуру, которая исполняет команды; про ядро ОС, имеющее полный доступ к памяти приложений; и так далее. Но, тем не менее, логическая концепция именно такая. Развитие этой идеи в ближайшем будущем приведёт к тому, что появятся “различные интернеты”, работающие внутри того или иного приложения. Но это другая история.

Вернёмся к DoH в браузере Firefox. Данный инструмент, сам по себе, не является универсальным средством, “позволяющим обходить все блокировки”, но он защищает от утечки информации о DNS-запросах/DNS-ответах на “последней миле”: то есть, на пути от резолвера до браузера. При этом браузер замыкает на стороне пользователя некоторый особый контур, в который теперь входит и защищённая доставка контента (TLS на веб-сайтах), и собственный сервис доменных имён. “Интернет – это то, что показывается в браузере”.

Что может сделать небольшой “гражданский дрон” (беспилотник) в случае, если из-за помех нет связи с пультом управления и также потерян сигнал спутниковой навигации? Понятно, что самое простое – это попытаться относительно медленно спуститься вниз и приземлиться. Такой вариант обычно и запрограммирован. Но оператору хотелось бы, чтобы дрон вернулся к нему в любом случае, если не точно в точку старта, то хотя бы оказался неподалёку от неё.

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

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

Да, точность в таком случае окажется низкой, будет накапливаться ошибка. Накопление ошибок – это основная проблема инерциальной навигации (для всех аппаратов, а не только для “гражданских беспилотников”). Даже небольшое, но непредсказуемое, “мгновенное отклонение” показателей датчиков, за несколько десятков минут полёта с интенсивным маневрированием вполне может привести к уводу измеряемых координат на сотни метров от реального положения аппарата. Но нам-то нужно решить довольно узкую задачу: автономное возвращение к оператору в критическом случае. Так что условия использования инерциальной навигации – тепличные: во-первых, пока работает спутниковая навигация, инерциальную систему можно эффективно корректировать, а история коррекции поможет фильтровать ошибки и после того, как аппарат перейдёт на полностью автономный полёт; во-вторых, возвращение к оператору должно происходить кратчайшим путём и без излишнего маневрирования, поэтому, в большинстве сценариев, автономный полёт займёт всего несколько минут, а аппарат будет стараться сохранять оптимальные для обеспечения точности “аварийной навигации” параметры ускорения. В общем, даже простая и не очень точная инерциальная система – справится.

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

Современный дрон содержит камеру, часто – не одну. Это хорошее подспорье для создания автономной навигации. Так, параметры движения можно определять по перемещению в поле зрения объектива “текстур” поверхности, над которой происходит полёт. Этот приём некоторые разработчики любительских дронов уже используют. Другой вариант – применение простого машинного зрения: у оператора может быть с собой некая визуальная метка (табличка с QR-кодом, например), в случае потери связи, оператор показывает эту метку в сторону дрона – если последний находится в прямой видимости, то он сможет обнаружить метку с помощью камеры и лететь в её сторону (дальность легко вычислить, зная оптические параметры объектива). Понятно, что метка должна быть не слишком маленькой, а объектив и камера – позволять её обнаружить.

Неплохим развитием этой идеи является какой-либо активный оптический канал, например, лазерный фонарик, который светит в сторону дрона некоторым модулированным сигналом. Во-первых, подобному сигналу на практике сложно поставить помеху (из-за того, что приёмник может быть выполнен узконаправленным, а помехопостановщик не сможет принимать подавляемый сигнал, если только не находится между дроном и источником, либо не видит каких-то отражений); во-вторых, сам сигнал может передавать дрону значение дальности до источника, а азимуты – определит приёмник.

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

Некоторое время назад в СМИ обсуждалось введение в Казахстане “обязательного TLS-сертификата”, который требовалось установить на клиентские устройства, что позволяло выполнять прозрачный перехват TLS-трафика. Эта история уже не новая: такая же схема обсуждалась в Казнете несколько лет назад.

Внедрение этого, весьма спорного, метода анализа защищённого трафика в 2019 году вызвало бурные возражения. В итоге: период, когда сертификат активно использовался (несколько недель в июле-августе 2019 года), сейчас обозначили как “тестирование применения сертификата безопасности”; сам сертификат теперь, после завершения “тестирования”, официально рекомендовано удалить с устройств (если пользователь его установил), для чего уже опубликованы инструкции.

Выпустил (некоторое время назад) очередное обновление технического описания протокола TLS.

Обновление не очень большое, тем не менее: во-первых, я перечитал весь текст и внёс мелкие правки, дополнения и исправления (в частности, исправил ряд опечаток, обнаруженных читателями); во-вторых, добавил краткое описание ESNI (технологии, позволяющей передавать имя сервера в защищённом виде); в третьих, опубликовал короткое приложение под названием “Конечные поля и эллиптические кривые в криптографии”.

Приложение, на мой взгляд, самое интересное в обновлении: это очень упрощённое и, надеюсь, доступное описание прикладной математической части, стоящей за реализациями “криптографии на эллиптических кривых”. Там нет известной картинки, иллюстрирующей метод секущих и касательных, а только алгебра (самая простая, она стоит за упомянутой картинкой), но это именно та алгебра, которая прямо используется в TLS на практике.

На сайте Statdom.ru (это проект Технического Центра Интернет) опубликована статистика по проникновению технологии ESNI в российских национальных доменных зонах. Напомню, что ESNI позволяет скрыть имя сервера, с которым соединяется клиент, при установлении TLS-соединения. Сейчас ESNI поддерживается браузером Firefox. На стороне сервера с поддержкой пока не очень хорошо, но Cloudflare её уже реализовали, поэтому заметное количество TLS-узлов ESNI уже поддерживают, а в Рунете уже свыше 140 тыс. доменов с ESNI.

Немного об одном интересном техническом аспекте. ESNI подразумевает размещение ключей в DNS, поэтому для сбора статистики требуется анализировать ресурсные записи. Соответствующий черновик RFC (draft-02) предписывает хранение данных ESNI в TXT-записи (Base64) для имени специального вида: _esni.name.tld (то есть, к имени узла, с которым устанавливается соединение, добавляется префикс _esni – подробнее описано в отдельной записке). Таким образом, для получения статистических данных выполняется сбор TXT-записей. При этом во многих случаях авторитативные серверы DNS так настроены, что отвечают на запрос TXT-записи для любого имени внутри зоны. Но, естественно, в ответ приходит не ESNI. Спецификация предусматривает для ESNI контрольную сумму, проверка значения этой суммы как раз и позволяет отличить настоящие ESNI от “каких-то” TXT-записей. Именно поэтому в отчёте на Statdom.ru присутствует колонка, в которой дано количество зон с некорректными TXT-записями для ESNI-имени.

Описанная только что проблема с размещением ESNI в DNS при помощи TXT-записей – известна. Поэтому более свежие версии черновика RFC предусматривают использование нового типа DNS-записи, специально выделенного для ESNI. Соответственно, после того, как такой тип выделят (и, скорее всего, появится RFC), ключи ESNI будут распространяться под именем без префикса _esni.

Особенно интересно, что в составе ESNI-записи смогут передаваться и адреса (IPv4, IPv6) узлов, с которыми клиенту следует соединяться, используя ключи ESNI. То есть, ESNI, фактически, замещает A- и AAAA-записи. (Конечно, всё это только после того, как появится новый тип и его поддержка DNS-серверами.)

На сайте ТЦИ также опубликована моя статья, популярно рассказывающая про технологию ESNI.

Добавил поддержку TLS 1.3 (это самая свежая версия протокола) на сервере, где работает dxdt.ru. Сейчас на сервере доступны только TLS 1.3 и TLS 1.2 (все более ранние – я отключил). Так как поддержка актуальной версии TLS требует подходящей версии Apache (собранного с веткой OpenSSL 1.1.1), то пришлось перейти с операционной системы CentOS 7 на Fedora 30, где все нужные сборки есть “из коробки” (вариант собрать “в сторонке” и OpenSSL, и Apache, и mod_ssl из исходников – как-то не очень, даже с учётом того, что мне это приходится проделывать в рамках других проектов). А в CentOS, к сожалению, непонятно когда появится TLS 1.3, данная ОС постепенно становится малопригодной для использования.

Тем не менее, вроде бы ничего особенно не сломалось, а сайт работает.

Под “спутниковыми интернетами” здесь подразумевается предоставление глобального “широкополосного” доступа к Интернету спутниковой группировкой. Таких систем предлагается несколько, а сами аппараты уже начали запускать: например, Starlink и OneWeb. Я уже писал, что подобная спутниковая система является отличной платформой для создания универсального орбитального радара, предназначенного для наблюдения за поверхностью Земли. В этот раз речь о другом: насколько легко будет обнаруживать наземные станции, используемые для доступа к данному спутниковому каналу связи?

Понятно, что наземный терминал должен излучать сигнал, который непосредственно может принимать спутник (варианты с доставкой одного “плеча” по традиционным наземным каналам – конечно, возможны, но это не то, чего ожидаешь от беспроводной “технологии будущего”). А раз терминал излучает, то его работу можно обнаружить при помощи пассивного приёмника. (Здесь необходима оговорка про направленные антенны: у антенн существуют боковые лепестки диаграммы направленности, они есть даже у узконаправленных антенн, а вопрос только в коэффициенте усиления утекающего сигнала; да, в теории, можно минимизировать боковые утечки, но такая антенна вряд ли подойдёт для спутникового терминала.)

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

Разместить приёмники, предназначенные для мониторинга радиоэфира, можно на вышках сотовой связи – они давно служат платформой для решения сходных задач: здесь есть куда поставить антенны, есть источники времени, есть каналы передачи данных и гарантированное питание. Соответствующее оборудование могут устанавливать те же “интеграторы”, которые разворачивают системы сотовой связи. Покрытие вышками в российских городах хорошее.

В теории, сигнал, используемый для организации спутникового канала, может быть замаскирован (например, если у наземного терминала и спутниковой группировки есть общие секретные ключи, то возможна реализация довольно “скрытного” кодирования). Однако, во-первых, резко упадёт пропускная способность, так что ни о каком “широкополосном” доступе речи уже идти не может; во-вторых – некоторый сигнал всё равно остаётся и его можно обнаружить, используя в качестве опорных сигналы специально закупленных терминалов и сигналы спутников. А главное, что о маскировке сигнала терминалов речи, конечно, не идет. Так что с обнаружением и геолокацией источников – проблем не возникнет.

(Записка с перечнем поддерживаемых элементов протокола TLS 1.3. Чтобы не потерялось.)

Тестовый сервер TLS 1.3 на tls13.1d.pw:

1. Версия протокола: 1.3 (0x0304), Draft-28 (совпадает с 1.3, кроме номера версии) и Draft-23 (в этой версии есть небольшие отличия в алгоритмах от 1.3, версия до сих пор встречается на практике). Вообще, draft-версии соответствуют черновикам RFC, протокол реализовывался (в статусе экспериментального) параллельно с разработкой RFC. Например, Draft-23 был очень распространён: его поддерживали и Firefox, и Chrome. Когда я запускал тестовый сервер, RFC ещё не было, и именно версия Draft-23 была основной.

2. Криптосистема подписи: сейчас используется ECDSA в группе P-384; раньше был вариант в группе P-256 (это названия кривых), можно сделать оба варианта (попеременно выбирать для каждого запроса), но тогда нужна обработка второго сертификата – возможно, добавлю. А вот поддержку RSA пока решил не добавлять.

3. Поддержка DH (при согласовании общего секрета в рамках установления соединения): P-256, P-384, x25519, а также “классический” FFDH с разрядностью 3072 бита (поддерживается, например, Firefox).

4. Шифры: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20Poly1305. Нет CCM-режимов.

5. Поддержка HelloRetryRequest: сервер, с некоторой вероятностью, отвечает на ClientHello сообщением пересогласования параметров – HelloRetryRequest (HRR), запрашивая другую группу из поддерживаемых клиентом; это происходит только в том случае, если набор групп, заявленный клиентом, позволяет. Это довольно богатое для целей исследования реализаций TLS направление, потому что здесь, в том или ином виде, требуется сохранение состояния соединения. Пример: предположим, что клиент заявляет для DH поддержку x25519, P-256 и FFDHE-3072, но ключ передаёт только для x25519 (это обычная ситуация в TLS 1.3); в таком случае сервер может ответить HelloRetryRequest, запросив либо P-256, либо FFDHE-3072.

6. Поддержка TLS cookie: при ответе с HelloRetryRequest – сервер передаёт клиенту TLS cookie. Это специальное расширение ClientHello/HelloRetryRequest, в котором передаётся некоторое значение – клиент должен вернуть это же значение в новом запросе ClientHello; у TLS cookie две основных роли: 1) “выгрузить” клиенту представление состояния начинающейся сессии, чтобы сервер не хранил дополнительные записи на своей стороне; 2) проверить, что клиент действительно активен и отвечает на запросы по адресу, с которого получено сообщение ClientHello. (Тестовый сервер совпадение значений TLS cookie не проверяет.)

7. Поддержка ESNI: поддерживается два варианта криптосистем DH – P-384, x25519 (в ESNI используется протокол Диффи-Хеллмана со статическими ключами, которые публикуются в DNS); шифр для ESNI – один: AES-128-GCM.

Некоторое время назад тестовый сервер TLS 1.3, который я реализовал и, в меру сил, поддерживаю по адресу tls13.1d.pw, продемонстрировал свою практическую полезность. А я забыл об этом написать на dxdt.ru – соответственно, пишу сейчас.

Тестовый сервер поддерживает сочетание HelloRetryRequest (HRR) и ESNI (зашифрованное поле SNI). То есть, сервер иногда отправляет клиенту запрос на пересогласование параметров и при этом обрабатывает ESNI. HRR+ESNI – весьма редкое сочетание, на обычном сервере скорее не встречается (но может быть имитировано в рамках активной атаки), это и позволило мне обнаружить в NSS (библиотека, используемая браузером Firefox) ошибку, которая до этого успешно прошла через релиз-тесты.

Ошибка состояла в следующем: использование ESNI должно скрывать имя сервера, но в NSS соединение с HRR+ESNI обрабатывалось некорректно, соответственно, во втором ClientHello, в ответ на запрос HRR, имя сервера передавалось в открытом виде (в обычном расширении SNI). В итоге – утекало имя сервера, а на tls13.1d.pw в некоторых случаях не удавалось отобразить сведения про ESNI для пользователей Firefox (причина в том, что во втором ClientHello, из которого только и имеет смысл брать сведения о соединении, ESNI просто не было). Об ошибке я сообщил в Mozilla, ошибка (Bug 1517714) исправлена в релизе NSS_3.43, вышедшем в марте. Сейчас исправленный релиз уже разошёлся по всем основным сборкам браузера Firefox.