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

Что касается STARTTLS. Для доставки электронной почты между почтовыми серверами в Интернете повсеместно используется протокол SMTP. SMTP – это “текстовый протокол”, то есть, его работа основана на командах, отправляемых в виде человекопонятного текста (ну, с точностью до числовых кодов состояний, которые, впрочем, тут тоже записываются ASCII-текстом) через любой подходящий транспорт. Многие достаточно древние протоколы в Интернете – текстовые. Потому что текстовые протоколы – это очень удобно и понятно. Там, где применимо. Сейчас, постепенно, этот подход возвращается (примеры: текстовые, REST-подобные API с JSON и др.), но, конечно, не везде.

Вернёмся к SMTP. Классические SMTP-сессии проходят в открытом виде, это означает, что содержание письма, доставленного электронной почтой, будет нетрудно просмотреть на любом промежуточном узле, которых легко могут быть десятки. (Обратите внимание, что дополнительные методы зашифрования содержания письма – PGP, S/MIME и т.д. – они относятся к другому уровню, не к SMTP.) Чтобы иметь возможность дополнительно защитить содержание писем в процессе доставки и используется STARTTLS: этот механизм позволяет SMTP-клиенту и SMTP-серверу перейти на защищённый канал “точка-точка” (см. пояснение ниже) после того, как они уже начали сессию в открытом варианте.

Для перехода к TLS, если сервер поддерживает STARTTLS, клиент просто отправляет команду STARTTLS (в виде текстовой строки, в открытом виде). Если сервер подтверждает, что готов к TLS, клиент в этом же “транспортном” сокете отправляет начальный пакет TLS-соединения (ClientHello, начинает “хендшейк”), после чего стороны могут согласовать защищённый сокет. Далее, если процесс установления TLS-соединения успешно завершился, SMTP-сессия начинается, фактически, заново, в текстовом формате, но уже внутри защищённого TLS транспорта. То есть, на логику SMTP использование STARTTLS влияет минимальным образом.

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

Поскольку сам SMTP полностью открыт, его не так уж трудно проксировать с изменениями, даже подменяя IP-адреса узлов. Серверное сообщение о поддержке STARTTLS можно просто вырезать из соответствующего ответа – если клиент допускает доставку без TLS, то он уже не будет пытаться установить TLS-соединение, а перейдёт к доставке в открытом виде. Это давно известная особенность, указанная в RFC.

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

Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в DNS, и в HTTP. А вот часть URL, соответствующая адресу документа, уже в DNS не ходит. Другими словами: используем в браузере (условный) URL https://123dio.cba.example.net/an-img.gif, где полезные данные кодируются в части 123dio.cba. Строка 123dio.cba.example.net отправится и в DNS, где будет узнана специальным сервером, и в HTTP, а вот an-img.gif – в DNS не попадёт, а поступит только на веб-сервер, отвечающий под 123dio.cba.example.net. Соответственно, насыщение HTTP-запросов полезной информацией, которую мы хотим видеть и в DNS, должно происходить через имена хостов.

Однако возникает неприятная проблема с HTTPS: дело в том, что для установления соединения с браузером сервер под “странным” именем 123dio.cba.example.net должен предъявить TLS-сертификат, валидный для этого имени, но имя-то каждый раз разное, поэтому сертификатов не напасёшься (если их выпускать через тот или иной УЦ, признаваемый браузерами). Использование открытого HTTP тут не рассматриваем – такие условия: хотя бы потому, что страница-носитель загружается по HTTPS. Что можно сделать? А можно, например, совсем отказаться от установления TLS-соединения на стороне сервера и при этом не потерять полезных данных. Нам не требуется реально обрабатывать HTTP-запрос и возвращать файл изображения, нам нужно только зафиксировать на сервере имя хоста, а это имя в HTTPS/TLS передаётся клиентом в начальном сообщении, да ещё и в открытом виде (это как раз и есть SNI TLS). Так что серверный сертификат тут просто не нужен: сервер записывает имя хоста из SNI и – прерывает соединение с тем или иным кодом ошибки TLS.

(Дополнение – 30/04/2023: в комментариях справедливо указывают на wildcard-сертификат для имён вида *.example.net. Однако тут такой сертификат не сработает, поскольку для DNS-части измерений важны кодирующие имена минимум в двух уровнях, то есть, *.*.example.com, а wildcard-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)

Кстати, в продолжение Certificate Transparency. Регулярно приходится сталкиваться с вопросами или предположениями относительно того или иного TLS-сертификата, которые сопровождаются недостаточным количеством “иллюстративных” данных. (Эта записка – рекомендации для обычных пользователей.)

Предположим, что вы где-то встретили или обнаружили “подозрительный TLS-сертификат” и хотите получить комментарии специалиста про этот сертификат. Как поступить?

Прежде всего: необходимо сохранить сам файл сертификата непосредственно и полностью. Скриншот окна Windows с информацией “об издателе” и со сроками действия – никак не позволяет что-то содержательное сказать о сертификате: по этим данным даже нельзя судить о том, разные сертификаты вы просматриваете или один и тот же. Сохранить сертификат можно при помощи функции экспорта. К сожалению, реализации этой функции существенно различаются от приложения к приложению. Например, в браузере нужно кликнуть на “замочек в адресной строке” или на вкладку панели веб-разработчика, соответствующую настройкам безопасности сайта, или ещё куда-то, но логика данного действия общая – нужно найти, где сертификат сервера (веб-сайта) экспортируется в файл. Файл может иметь разные форматы (Base64, “двоичный”) и разные расширения в имени (.pem, .cer, .der, .bin, .cert и др.), но это, обычно, не важно – для специалиста это редко является проблемой. Главное – получить сам сертификат полностью в файле. Если функция экспорта позволяет сохранить “цепочку сертификатов” – тем лучше, сохраните цепочку. Основная причина, по которой нужен именно файл, в том, что сертификат содержит значение подписи, а это значение является доказательством того, что сертификат действительно был выпущен и подписан с использованием того или иного ключа. Кроме того – можно удобным способом просматривать все поля сертификата (серийный номер, расширения, ключ и пр.).

Если вам по каким-то причинам удаётся просмотреть только значения конкретных полей сертификата, то, во-первых, нужно сразу отметить, что ценной информации будет очень мало, и, во-вторых, попытаться сохранить серийный номер, отпечаток сертификата (значение хеш-функции для сертификата), имена, – то есть, название УЦ и имя, для которого сертификат выпущен (Issuer, Subject, Subject Alternative Name), – значение ключа (или отпечаток ключа; в сертификате публикуется открытый ключ) и тип криптосистемы, значение подписи с указанием на тип криптосистемы, сроки действия и сведения о цепочке сертификатов (серийные номера, имена, отпечатки), использованной для валидации.

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

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

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

При вычислении подписи для пресертификата сервис CT-лога использует в качестве входных данных не весь сертификат, а только его “содержательную часть” (некоторое зафиксированное в структуре подмножество полей), из которой, к тому же, удаляется poison-расширение. Это, что называется, первый “сюрприз”: poison-расширение должно присутствовать в составе поступающего пресертификата не только потому, что оно и делает сертификат пресертификатом, но и потому, что иначе не сойдётся подпись УЦ на пресертификате, а подпись должен проверить сервис лога. Дописать какие-то данные в сертификат не выйдет. Однако поскольку в сертификате Poison удаляется, то и подпись в SCT нужна на данных без poison-расширения. Второй “сюрприз”: при проверке подписи SCT в сертификате – нужно восстановить содержательную часть пресертификата в точно таком виде, какой передавался в сервис CT-лога, но с учётом удаления Poison – то есть, нужно удалить “лишние” расширения (SCT-метки), а те расширения, которые останутся, должны совпасть с конфигурацией пресертифката. А поскольку такое преобразование снова удаляет из состава сертификата значение подписи, к данным сертификата, перед проверкой, вместе с другими служебными параметрами SCT, нужно присоединить отпечаток открытого ключа УЦ. Понятно, что то же самое делается и на стороне CT-лога, при формировании SCT. Так что общий алгоритм местами “макаронный”, но, тем не менее, используется. Не удивительно, что в новой версии CT пресертификатов нет.

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.

Цитата из моего технического описания TLS:

Весьма полезной практикой является разумное выравнивание стойкости используемых криптосистем. Например, в подавляющем большинстве случаев не имеет смысла использовать RSA-ключ длиной в 4096 бит, если ваш TLS-сервер всё ещё поддерживает SSLv3, а в качестве симметричного шифра применяет DES с 56-битным ключом.

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

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

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

Подборка некоторых публикаций про TLS на dxdt.ru (и около):

Несколько реплик про перехват TLS при помощи MitM (дополнение о проверке сертификатов);
Браузеры и перехват TLS без участия УЦ;
TLS для DevOps;
Популярно о перехвате HTTPS;
TLS, зашифрованные протоколы и DPI;
Сеансовые ключи (DH) в трафике TLS;
Техническое: перехват TLS (HTTPS), некоторые тонкости;
TLS 1.3: на пути к внедрению.

Процитирую заметку из 2016 года, про MITM для TLS:

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

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

В продолжение заметки про TLS-сертификаты и роль Certificate Transparency. Конечно, наличие меток логов Certificate Transparency может служить в качестве дополнительного признака при валидации сертификата браузером. Однако нужно учитывать тот факт, что сама по себе корректная SCT-метка в сертификате вовсе не означает, что данный сертификат был добавлен в лог. Дело в том, что для получения корректной метки достаточно знать сам исходный сертификат (чтобы вычислить значение хеш-функции) и знать секретный ключ лога (чтобы вычислить значение подписи). Собственно, сами SCT-метки появились для того, чтобы отделить вычислительно сложный процесс добавления сертификата в лог от процесса создания метки, предназначенной для включения в сертификат. Согласно планам применения, наличие метки означает, что оператор лога видел сертификат (и должен включить его в лог, иначе оператор нарушает некоторые правила). Если же посмотреть на этот процесс строго, то наличие метки в сертификате означает, что сертификат видела сторона, знающая секретный ключ лога. Поэтому, если клиентская программа, – например, браузер, – не проверяет наличие сертификата непосредственно в логе, а полагается лишь на корректную SCT-метку, полученную в сертификате, то и проверяет такая программа только дополнительную подпись на сертификате, не более того. То есть, для выпуска валидного сертификата с валидной меткой, стороне, которая выпускает такой сертификат, потребуется доступ к двум ключам – удостоверяющего центра и оператора лога (и не обязательно, что эти две роли играют совершенно разные организации). Не более того.

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

Certificate Transparency – это набор связанных с иерархией Удостоверяющих Центров (УЦ) TLS технологий, который позволяет вести специальные логи выпускаемых и выпущенных сертификатов. Предполагается, что логи общедоступны, а их наличие позволит обнаружить сертификаты, выпущенные с нарушением правил. Чтобы усилить действие Certificate Transparency (CT), браузеры (или другие программы, которые выполняют валидацию сертификатов) могут требовать подтверждения того, что конкретный сертификат был учтён в том или ином логе CT. Удобная реализация такого требования подразумевает наличие некоторых подписанных ключами логов меток в составе самого сертификата. Такие метки называются SCT – Signed Certificate Timestamp.

Метку SCT выдаёт оператор CT-лога в ответ на добавление сертификата в лог. Когда Certificate Transparency первой версии только проектировали, то этот момент, к сожалению, не учитывали. Поэтому проявилась проблема “курицы и яйца”: чтобы выпустить сертификат с SCT-меткой – нужно получить метку, а чтобы получить метку – нужно выпустить сертификат (для того, чтобы отправить его в лог). В качестве некоторого “обходного решения” (“костыля” – скажут те, кто “хорошо в теме”) предложили ввести пресертификаты.

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

Тем не менее, пресертификаты широко используются в CT: УЦ, готовясь выпустить сертификат с SCT-меткой, прежде генерирует и подписывает пресертификат с теми же параметрами (имя, серийный номер и т.д.), но с poison-расширением, отправляет пресертификат в CT-лог, получает в ответ метку с подписью лога, которую уже размещает в полноценный сертификат. Таким образом в логе возникает отметка о пресертификате, которая позволяет получить все содержательные данные о сертификате. В сертификате же появляется SCT-метка, подтверждающая, что оператор лога видел сведения о сертификате. Валидность метки может проверить валидирующая программа – для проверки используется ключ лога. Этот процесс нарушает рекомендации по работе УЦ, поскольку запрещено выпускать два сертификата с одним серийным номером (и одним именем УЦ), но этот момент принято выносить за скобки.

Впрочем, во второй версии Certificate Transparency от пресертификатов отказались – для размещения сведений о сертификате используются сообщения другого формата, их формирование не требует выпуска как бы настоящего, но “испорченного” сертификата.

Если из браузера утекают сеансовые ключи, то расшифровывать TLS-трафик можно в пассивном режиме, и не потребуются никакие “перехватывающие удостоверяющие центры”. А намеренную утечку может организовать сам браузер. Или другой клиент TLS. А также и сервер. Довольно интересно в этом контексте выглядит распространённая сейчас в мире персональных компьютеров ситуация, когда TLS-трафик перехватывает и проксирует локальный антивирус.

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

Утечку можно организовать самыми разными способами. Например, начальные сообщения сеанса TLS содержат случайные значения, которые, конечно, могут быть “не совсем случайными”. Более ловкие варианты основаны на манипуляции длиной сообщений (или пакетов данных), на передаче дополнительных параметров и так далее. Главное – каким-то способом поставить измеримую характеристику трафика в зависимость от состояния генератора псевдослучайных чисел клиента. Самое занимательное, что наличие такой зависимости может быть неплохо обосновано “желанием замаскировать метаинформацию о соединении”.

А использование подменного УЦ – это довольно грубый метод. Который, во-первых, требует активного перехвата соединения; во-вторых – оставляет надёжные, хорошо заметные следы.