Доступ к скрытым TLS-сервисам: Encrypted Client Hello

Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ

TLS (Transport Layer Security) – это традиционный инструмент защиты информации в глобальной Сети. Для веба этот протокол фундаментален, так как именно с его помощью реализуется защищённый доступ к веб-сайтам по HTTPS. Именно поэтому мы постоянно возвращаемся к TLS в наших публикациях.

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

Для передачи этого имени служит специальное поле данных - SNI (Server Name Indication). Указание имени сервера требуется, чтобы на стороне сервера возможно было выбрать подходящий сертификат, если сертификатов используется несколько. На заре распространения технологий SSL/TLS предполагалось, что TLS-сервер работает на выделенном IP-адресе, привязанном к единственному имени веб-ресурса. В такой конфигурации проблемы с определением нужного сертификата нет - имя всего одно. Позже, когда на одном IP-адресе стали размещать сотни и тысячи веб-узлов, использование SNI для HTTPS стало необходимым, а сейчас оно просто обязательно для универсального клиента, поскольку некоторые сервисы вообще недоступны без указания SNI, даже если используют выделенный IP-адрес. В современной ситуации "множественность" имён, соответствующих одному IP-адресу, служит неплохим средством маскировки, однако передача SNI в открытом виде позволяет легко определить, с каким именно сервисом соединяется клиент, - сделать это можно при помощи пассивного прослушивания трафика.

Текстовый дамп сообщения Client Hello, в котором выделена строка, содержащая имя сервера www.google.com

Для сокрытия имени сервера была предложена технология ESNI (Encrypted SNI). С момента публикации на нашем сайте статьи, рассказывающей об этой технологии, прошло более двух лет. Спецификация ESNI имела тогда статус черновика (draft RFC), но при этом уже поддерживалась браузером Firefox в порядке эксперимента. А поскольку серверную часть эксперимента обеспечивал популярный провайдер Cloudflare, то и ESNI удалось протестировать на большом объёме реального HTTPS-трафика. За прошедшее время технология сильно изменилась. Можно сказать, изменилась до неузнаваемости, потому что даже называется теперь иначе: ECH (Encrypted Client Hello). При этом работа над окончательной версией спецификации всё ещё не завершена. Сокрытие имени сервера (SNI) было главной и единственной задачей ESNI, однако к моменту превращения ESNI в ECH эта задача получила кучу уточнений, оговорок и дополнений, превратившись в большой набор сопутствующих проблем, решить которые предлагается в новой спецификации.

Почему вообще актуально добавление в TLS механизма, скрывающего факт доступа к некоторому сервису? Типовое объяснение такое: в современных условиях работы приложений, использующих Интернет, важно минимизировать возможности технически продвинутой третьей стороны по построению статистики логических соединений. Ключевое слово - "логических", потому что речь именно о том, какие конкретные информационные системы посещает пользователь, а не о том, с какими IP-адресами соединяется его компьютер. Существует и менее типовое объяснение: Интернет под воздействием технологических гигантов активно движется в ту сторону, в которой большая часть содержательной коммуникации окажется скрытой в защитном тумане. Новые коммуникационные протоколы можно фактически называть протоколами "дымовой завесы": содержательная деятельность - обмен текстовыми сообщениями, просмотр веб-страниц - происходит на уровне приложений и полностью скрыта от средств пассивного анализа трафика. Пассивный анализ же показывает только факт установления сессий связи между IP-адресами, но даже по этим IP-адресам, которые постоянно перемешиваются, нельзя сказать о том, какие приложения использовали эти сессии. ECH - один из важных шагов на пути к такой "дымовой завесе".

Основным отличием ECH от ESNI является то, что ECH в некотором смысле гораздо шире: ESNI лишь предлагала добавить в протокол одно поле, которое служит для передачи имени сервера в зашифрованном виде, а все остальные элементы оставались без изменений. В TLS установление соединения начинается с отправки клиентом в сторону сервера начального сообщения, которое и называется Client Hello. Это сообщение содержит много различных полей. В нём указываются криптографические параметры, схемы и версии протокола, которые поддерживает клиент, вспомогательные данные. И если ESNI лишь добавляет одно поле (такие поля называют "расширениями", но для наших целей это не важно), то ECH предписывает использовать целое дополнительное сообщение Client Hello.

То есть ECH идёт гораздо дальше ESNI и предполагает полноценное туннелирование TLS-соединения. Используя эту технологию, клиент не просто скрывает имя узла, но устанавливает скрытое TLS-соединение со скрытым сервисом, которому направляется секретное начальное сообщение. При этом "внешнее" TLS-соединение таковым соединением вовсе не является, поскольку представляет собой лишь логический "контейнер", позволяющий клиенту обменяться параметрами соединения со скрытым сервисом. Естественно, туннелирование соединения позволяет скрыть имя сервиса, это его минимальная задача. Однако туннелирование ECH даёт гораздо больше возможностей, оно удобнее для массового сервиса. Это важное отличие двух вариантов решения одной исходной задачи, и оно хорошо иллюстрирует современное направление развития фундаментальных интернет-технологий.

В ECH сохранилась концепция распределения ключей, изначально предложенная для ESNI. Однако теперь вводится новая ресурсная запись DNS, предназначенная для публикации настроек доступа к интернет-сервисам, в том числе к скрытым. В ESNI ключи тоже предлагалось получать через DNS, но они публиковались в TXT-записях. TXT-записи предоставляют универсальный механизм публикации произвольных данных в DNS, но универсальность порождает и дополнительные проблемы: например, массовым сервисам может быть сложно "сортировать" TXT-записи, относящиеся к разным технологиям, но совпадающие по именам; клиентам - сложно выделить нужные записи из большого массива, который может прийти в ответ на запрос, и это в том случае, если TXT-записи вообще удалось извлечь. Более того, расширение списка ресурсных записей DNS создаёт в этой системе новый инструмент, позволяющий клиентам получать подробную информацию о том, каким способом и с какими сервисами он может соединяться в текущей "сетевой ситуации". В свою очередь, "сетевая ситуация" складывается из доступности тех или иных узлов и точек входа: доступность может быть ограничена как по чисто техническим, так и по административным причинам. Естественно, ключи, необходимые для начала работы, могут быть встроены в дистрибутив клиента, то есть не требовать наличия корректно работающей DNS для развёртывания.

С распространением технологий, подобных ECH, даже для обладающего обширными наборами инспектирующих узлов пассивного анализатора трафика, вся метаинформация о сессиях на уровне приложений сведётся к двум не очень информативным слоям: IP-адреса обменивающихся пакетами узлов и, во втором слое, минимальные описания сессий, соответствующие тому начальному процессу, который принято называть "поиском сервиса" (service discovery). При этом построение этого второго слоя окажется очень трудной задачей, решение которой потребует наличия развитых мощностей систем DPI. Дело в том, что отдельные элементы второго слоя эффективно распределяются по разным протоколам. Так, часть информации передаётся через DNS по UDP и TCP, другая часть - по HTTPS через TCP, или, например, QUIC. Протоколы могут интенсивно перемешиваться: не получив нужного ответа через простой запрос к DNS, приложение может переключиться на DNS-over-HTTPS. Более того, наметившаяся логика построения подобных протоколов гарантирует, что и клиент, и сервер смогут использовать при поиске подходящих узлов и ключей метод “угадывания с предварительной информацией”, перебирая адреса, имена и ключи по известному алгоритму. Конечно, ECH пока ещё далека от такой схемы, но метод пробного расшифрования там уже используется для того, чтобы на стороне сервера сопоставить ключи и скрытое соединение. Несомненно, потребуются дополнительные вычислительные затраты. Но для действующей согласованно пары узлов эти затраты будут несравнимо меньше количества вычислений, которые должна будет выполнить прослушивающая сторона, чтобы раскрыть небольшую часть метаинформации о соединении.

Итак, ECH является существенным шагом вперёд, по сравнению с ESNI, и позволяет клиенту обращаться к скрытым сервисам в защищённом режиме. Существенным фактором маскировки является то, что такой сервис может разделять IP-адрес со множеством других сервисов. При правильном использовании ECH доступ к любому из этих сервисов нельзя отличить от доступа к другому: прослушивающая канал обмена данными сторона может лишь определить факт установления TLS-соединения с данным IP-адресом, но не более того. Впрочем, то, что конкретное соединение могло использовать скрытый сервис, технология ECH напрямую не скрывает, однако позволяет реализовать эффективную маскировку и в этом направлении: дело в том, что клиент может для заданных IP-адресов использовать только соединения с ECH. Усиление роли DNS позволяет клиентам, реализующим новую технологию, быстро адаптироваться к изменяющейся конфигурации глобального сетевого транспорта.