ESNI как защита TLS от утечек метаинформации

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

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

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

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

На стороне сервера поле SNI необходимо для того, чтобы возможно было выбрать подходящий по имени сертификат, если их используется несколько. В современной ситуации, когда общий IP-адрес соответствует сотням и тысячам различных веб-узлов, без SNI HTTPS вообще не будет работать. Если сервер не может определить, какой именно сертификат предъявить клиенту, то соединение в подавляющем большинстве случаев использования веб-технологий окажется некорректным, так как нарушится работа механизма аутентификации. Поэтому, несмотря на то, что SNI не является строго необходимым в TLS полем, его повсеместно поддерживают и серверы, и браузеры.

SNI передаётся в открытом виде даже в самой современной версии протокола TLS - 1.3. Поэтому прослушивающая трафик сторона видит, с каким именно узлом пытается установить TLS-соединение клиент. Конечно, если говорить строго, то третья сторона видит лишь имя узла, переданное в SNI: клиент, по договорённости с сервером, мог записать в это поле что угодно. Тем не менее в типичном сценарии передаётся именно подлинное имя узла - например, когда пользователь открывает веб-сайт при помощи браузера. Таким образом, SNI создаёт канал утечки чувствительной информации. Логичным шагом является закрытие этого канала при помощи криптографии. Этот аспект, конечно, рассматривался при разработке новой версии TLS, но рабочая группа решила не требовать зашифрования SNI в спецификации самого протокола. Вместо этого предложен отдельный документ, описывающий зашифрованную версию SNI - Encrypted SNI.

Необходимо заметить, что, поскольку проблема с утечкой имени узла через SNI давно и хорошо известна среди специалистов, предлагалось сразу несколько решений. Сейчас ещё нет утверждённого согласно процессу IETF документа RFC, но уже можно предположить, какой вариант в итоге будет внедряться. Это вариант, который - на стороне клиента - уже реализован в браузере Firefox, а на стороне сервера — Cloudflare, одним из крупнейших мировых провайдеров CDN. Несмотря на то, что решение уже используется, спецификация пока (май 2019) находится в статусе черновика (Draft), тем не менее основные принципы работы протокола уже ясны.

ESNI работает только вместе с TLS версии 1.3 (и выше, но сейчас 1.3 самая свежая). Поле ESNI устроено сложнее, чем SNI, так как для обеспечения защиты используются дополнительные данные. Клиент зашифровывает имя сервера с помощью симметричного шифра и на начальном этапе установления соединения отправляет это имя серверу в защищённом виде, разместив в поле ESNI. Сервер, получив сообщение клиента, расшифровывает имя и использует его значение при выполнении дальнейших шагов, например, при выборе серверного сертификата (использование ESNI допускает также проксирование соединения на скрытый сервер). Главный вопрос, возникающий при внимательном рассмотрении данной схемы, такой: откуда сервер и клиент получают общий симметричный ключ? Такой ключ необходим клиенту для того, чтобы зашифровать имя в ESNI, а серверу - для расшифрования. Ответ: для получения общего секретного ключа стороны используют информацию, опубликованную в DNS (в системе доменных имён). Это важная особенность ESNI — в действующей версии этот протокол базируется на DNS (но в будущем возможны и другие варианты распределения ключей).

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

Для адресации DNS-записей, содержащих открытый серверный ключ ESNI, используется DNS-имя специального вида: _esni.example.com. Здесь домен example.com выбран для примера, он адресует сервер, с которым устанавливается соединение. Так, если браузер, поддерживающий ESNI, устанавливает соединение с веб-узлом, адресуемым именем test.ru, то из DNS запрашивается запись с именем _esni.test.ru. Другими словами, к имени веб-узла добавляется префикс _esni (символ "нижнее подчёркивание" необходим для того, чтобы отличать специальную запись от так называемого имени хоста - в именах хостов "нижнее подчёркивание" не допускается).

Очевидно, что если имя домена (за исключением префикса _esni) совпадает с именем узла, с которым браузер пытается установить соединение, то утечка, от которой планировалось защититься, теперь происходит через DNS-запрос. Это означает, что для DNS также необходимо использовать защищённый транспорт. Предполагается, что это будет DNS-over-TLS или DNS-over-HTTPS (в современных версиях браузера Firefox, поддерживающих ESNI, используется DNS-over-HTTPS.) Оба протокола позволяют защитить от перехвата и модификации канал "последней мили", то есть от браузера до DNS-резолвера, выполняющего рекурсивный опрос DNS. Отметим, что если пользователь не доверяет данному резолверу, то прямое использование ESNI теряет смысл: резолвер может просматривать все запросы пользователя. Впрочем, спецификация ESNI не исключает конфигурацию, когда открытые ключи из DNS извлекаются по другому имени, которое не связано с целевым узлом. Внедрение ESNI также подразумевает использование DNSSEC для защиты от подмены адресной информации в DNS - иначе третья сторона может подставить свои ключи вместо подлинных и получить доступ к содержанию поля ESNI.

Использование DNS в качестве одного из основных элементов ESNI позволяет строить статистику по доменным именам, для которых данная технология уже включена. Технический Центр Интернет разместил соответствующий отчёт на сайте проекта «Домены России». Несмотря на то, что технология только появилась и пока ещё работает в статусе черновика (Draft), в российских доменах верхнего уровня поддержка ESNI уже заметна: так, по состоянию на июнь 2019 года ESNI-записи указаны более чем для 140 000 доменных имён второго уровня. Это прямое влияние DNS-хостинга Cloudflare, на котором размещены соответствующие доменные зоны, что подтверждается и очень низким разнообразием опубликованных ключей (спецификация допускает использование общего ключа для разных зон, это не оказывает существенного влияния на уровень защиты). В отчёт включаются только те записи, которые успешно прошли проверку корректности.