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

Некоторое время назад в СМИ обсуждалось введение в Казахстане “обязательного 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.

Существенная часть информации о TLS-соединении доступна системам инспекции трафика (DPI). Чаще всего, конечно, упоминается поле SNI (Server Name Indication), в котором передаётся имя сервера. Для маскировки SNI в TLS 1.3 уже предложен дополнительный механизм Encrypted SNI.

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

В открытом виде (версии меньше 1.3) на начальном этапе передаются и клиентские сертификаты, которые в TLS используются для аутентификации клиента сервером. Клиентские сертификаты часто применяются в решениях VPN, соответственно, анализ клиентского сертификата в этих случаях позволяет точно распознать начало VPN-соединения.

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

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

DPI видит длину отдельных TLS-записей. Однако TLS позволяет приложению разными способами маскировать реальную длину передаваемых данных. А в TLS 1.3 имеется специально для этой цели предназначенный механизм на уровне защищённого транспорта: длина записей может выравниваться с помощью дополнения. Это означает, что реализация в версии 1.3, минимизирующая утечки метафинформации, может превратить поток данных в последовательность TLS-записей одинакового типа и одинаковой длины – DPI будет сложно за что-то зацепиться.

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

Естественно, хорошо защищённый протокол должен свести к минимуму утечки метаинформации. Это, частично, уже сделано в TLS 1.3, однако TLS является весьма универсальным протоколом, который, к тому же, проектировался с учётом повышения его эффективности в роли транспорта для массовых соединений, а не как протокол, скрытый от DPI. Поэтому пассивные анализаторы трафика всё ещё получают из TLS-соединения дополнительную информацию об узлах и состоянии приложений (дополнительную – по сравнению, например, с информацией уровня TCP, к которой относятся адреса узлов, номера портов, порядок и размер TCP-пакетов и др.). Методы криптографии позволяют спроектировать хорошо замаскированный протокол, но каждый шаг маскировки снижает эффективность, в частности, увеличивает затраты на установление соединения (это перебор адресов, генерация дополнительных секретов и т.д.). Тем не менее, ситуация тут такова, что даже небольшой, но верно спланированный шаг маскировки – существенно затрудняет работу DPI. В ряде случаев, рост “сравнительной сложности” на стороне DPI оказывается, как минимум, экспоненциальным: представьте, что специальный протокол использует перемешивание UDP-пакетов разных потоков, отправляемых по различным адресам серверов.

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

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

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

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

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

Итак, какими свойствами и механизмами должен обладать скрытый протокол в таких (весьма жёстких) условиях?

1.

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

2.

Для сокрытия трафика необходимо использовать стеганографию. В принятой модели угроз, если один из узлов просто передаёт зашифрованное сообщение вне прочих сеансов, то этот факт тут же оказывается обнаружен. Стеганографический канал маскирует сеанс обмена сообщениями под трафик другого типа. Это означает, что протокол не может прямо использовать привычные виды транспорта, а должен подразумевать наличие дополнительного трафика. Простой пример: сообщения могут быть скрыты внутри текстов веб-страниц и веб-форм, в качестве базового трафика используется имитация работы с веб-сайтом. В данном случае, веб-трафик может передаваться по TCP или UDP, с использованием TLS/HTTPS или QUIC, экзотические варианты вместо веб-трафика используют непосредственно TLS, или даже служебные заголовки IP-пакетов и DNS, всё это не так важно для стеганографии. Важны достаточный объём данных и наличие симметричных ключей, позволяющих организовать стойкий стеганографический канал. При наличии ключей – такой канал организовать всегда можно. (Ключи используются для задания псевдослучайной последовательности, которая необходима для работы механизма встраивания скрытых данных в поток трафика.)

3.

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

4.

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

5.

Выбранная модель угроз гарантирует, что третья сторона может использовать подставные узлы, имитирующие узлы-участники скрытого обмена сообщениями. Если протокол поддерживает возможность создания новых каналов обмена сообщениями и подключения новых узлов (а это часто необходимо), то возникает ещё одна непростая задача: как отличить деятельность атакующей третьей стороны от настоящих участников обмена? Одним из вариантов решения является удостоверение ключей новых участников ключами уже работающих узлов (напоминает практику PGP). Однако, в случае скрытого протокола, процедура такого удостоверения может оказаться весьма сложной: как и где обмениваться подписями, не раскрывая факта такого обмена и идентификаторов узлов? Предположим, что скрытым протоколом хотят воспользоваться два участника, которые раньше сообщениями не обменивались – понятно, что у них, в общем случае, нет возможности отличить подставной узел от подлинного корреспондента. Можно было бы заблаговременно раздать всем некоторый общий открытый ключ, который будет удостоверять новые узлы, но в таком случае возникает центральная схема, которой все должны доверять, в том числе, новые участники. К тому же, схема неустойчива к утрате соответствующего секретного ключа (и кто его будет хранить?) Похоже, кроме варианта с предварительным распределением многих личных ключей, остаётся только офлайновый обмен (опять же, вспоминается PGP).

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