Слабые ключи eMudhra открыли дорогу поддельным HTTPS-сертификатам

Суть проблемы в том, что вместо случайных 384-битных значений eMudhra создавал ключи, соответствующие числам от 4 до 237. Восемь закрытых ключей восстанавливаются менее чем за секунду — подобрать их может любой, кто знает, где искать. А из восстановленного ключа выпускается сертификат, которому устройства доверяют как настоящему.

Подделки пошли в ход почти сразу: один сертификат датирован 20 октября, менее чем через час после публичного раскрытия ошибки в системе отслеживания Mozilla. Cloudflare с 21 октября отслеживала подозрительные соединения через прокси Pingora и насчитала около 22 тысяч попыток TLS-соединений с проблемными сертификатами. Примерно две трети приходились на тестовые сайты, почти все остальные — на серверы, владельцы которых, предположительно, сами выпустили сертификаты. Но около 160 соединений содержали сертификаты с чужими доменными именами, включая адреса устройств IoT, а некоторые из них действовали более двух лет.

Масштаб доверия впечатляет: среди встроенных браузерных компонентов Android WebView доля принимающих скомпрометированные цепочки составляла 30–40%, а в трафике крупных сетей более половины проверок завершались принятием опасной цепочки. Cloudflare подчёркивает, что выборка смещена в сторону ботов и проценты нельзя переносить на всех пользователей, а признаков перехвата соединений она не обнаружила. При этом отсутствие следов массовых атак не исключает целенаправленного перехвата трафика — это мнение Cloudflare, а не установленный факт.

Почему это важно российским компаниям

В российской практике такие сценарии чаще всего всплывают там, где доверие к сертификатам задаётся годами и редко пересматривается: в парке IoT-устройств, в промышленных и торговых сетях, во встроенных браузерных компонентах мобильных приложений и в автоматизированных клиентах, которые ходят в интернет без человека. Если устройство принимает поддельную цепочку, оно не отличит чужой сервер от настоящего, и защищённый канал перестаёт быть защищённым. Отдельный риск — устаревшие хранилища сертификатов и библиотеки TLS, которые не получают обновлений вместе с остальной системой.

Что делать с сертификатами и доверием

Cloudflare начала устранять проблему 19 октября, анализ исходного кода с помощью ИИ помог за четыре часа выявить остальные уязвимые компоненты, а к 30 октября все приоритетные системы получили исправления. eMudhra объявила об уходе с рынка публичных центров сертификации и связывает слабые ключи с ошибкой в сценарии генерации, но исходный код сценария не раскрыла. Компаниям стоит обновлять приложения, библиотеки TLS и хранилища сертификатов, а также развивать механизмы быстрого отзыва доверия — чтобы скомпрометированный сертификат переставал приниматься раньше, чем им воспользуются. Полезно заранее знать, какие устройства и клиенты в парке доверяют внешним цепочкам, и иметь план их отключения.