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

Если вы записываете IP-трафик на промежуточном узле, то можно ли в записи обнаружить использование в TLS-сессиях серверных TLS-сертификатов, выпущенных от нестойких ключей доверенного УЦ eMudhra? Можно, но не всегда.

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

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

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

Почему вообще такие TLS-сертификаты могли использоваться? В теории, распространённые браузеры должны проверять метки логов Certificate Transparency в сертификатах, и если сертификат не имеет валидных меток доверенных логов, то браузер не должен верить в такой сертификат. Метки логов можно получить штатным образом, зная подписывающий секретный ключ УЦ. Но дело даже не в этом. Дело в том, что далеко не только браузеры используют TLS. А различные прочие клиенты, которых много разных, вовсе не проверяют метки логов и не требуют их наличия в сертификате. Так что подмена работала (и работает) для многих устройств и приложений. Один из шумных практических примеров – неожиданно грубая ошибка в ПО такого устройства, как “Яндекс.Станция”, позволившая атакующему подставлять свой программный код при помощи атаки типа “Человек посередине”, с использованием тех самых тривиальных ключей eMudhra. Шумность данной проблемы обсуловлена тем, что тривиальность ошибки может легко посморить с тривиальностью самих ключей: доверенных “из коробки” УЦ – сотни, и устройство не может их никак контролировать, проверять нужно отпечатки ключей, а не доверять только коробочным УЦ.

Так что практических случаев применения скомпрометированных ключей очень много. И трудностей тут добавляет то, что проблемные ключи были подписаны другим доверенным УЦ – Sectigo, который горазодо более распространён. То есть, чтобы атака сработала – было достаточно доверия корневым ключам Sectigo.

Итак, в принципе, использование подменных сертификатов, выпущенных от триваильных ключей, можно увидеть в записи трафика, и такие сертификаты могли использоваться ранее. Однако если запись трафика не велась, либо если атакуемым устройством/приложением использовалась только актуальная версия TLS 1.3, где сертификаты передаются в зашированном виде, увидеть уже ничего не получится. Как говорится, “были сертификаты или нет – науке это не известно”. Однако с точки зрения теории защиты информации необходимо считать, что сертификаты такие были. И речь тут – только про TLS, но X.509-сертификаты используются и в других областях.

Адрес записки: https://dxdt.blog/2026/11/04/19568/