Hacker News Digest

Индийская компания eMudhra объявила о добровольном уходе из глобального бизнеса SSL/TLS-сертификатов. Поводом стал недавний инцидент, связанный с её удостоверяющим центром: компания отозвала затронутые центры сертификации в течение 14 часов после обнаружения и своевременно раскрыла информацию. Конечным объектам сертификаты из пострадавшего центра не выдавались, инфраструктура не была скомпрометирована, утечки данных не произошло, все физические и логические средства защиты остались в целости.

Председатель совета директоров В. Сринивасан отметил, что глобальный SSL/TLS приносит лишь около 1% мировой выручки. Из-за роста требований к суверенитету данных и соответствию нормам сложность и стоимость этого направления растут, а крупные игроки выдают такие сертификаты бесплатно — рентабельность заметно снизилась. При этом шумиха в соцсетях вокруг инцидента привела к несоразмерному вниманию. Для многих удостоверяющих центров SSL/TLS — весь бизнес, но для eMudhra это лишь часть широкого портфеля, поэтому компания сосредоточится на корпоративных решениях и трастовых услугах.

Переход пройдёт безболезненно: корневые сертификаты G1 RSA продолжат работать до его завершения, клиентам бесплатно заменят сертификаты, а сервисы отзыва и статуса будут действовать, пока все выданные сертификаты не истекут или не будут заменены. Компания также выполнит обязательства перед программами корневых сертификатов браузеров, включая полный отчёт о причинах. Остальные направления — цифровая подпись, eSign, корпоративные PKI-платформы emCA и CertiNext, набор emSigner, решения идентификации SecurePass и emAS — работают в обычном режиме.

Обсуждение содержит крайне негативную оценку компетенций eMudhra: утечка приватного ключа считается катастрофической ошибкой, ставящей под сомнение безопасность всех продуктов компании (включая CertiNext и emCA) и её криптографические процессы. Пользователи обвиняют eMudhra в манипуляциях и попытке уйти от ответственности, так как утверждение об «отсутствии компрометации инфраструктуры» противоречит факту утечки ключа CA. Также критикуется скорость реакции: отзыв CA через 14 часов не считается оперативным, а заявляемое отсутствие выданных сертификатов нивелируется тем, что любой мог выпустить их самостоятельно. По опыту @Arbortheus, некоторые iPhone 15 Pro принимали скомпрометированные сертификаты даже спустя 5 дней после уведомления Apple. Отмечается системная уязвимость Web PKI из-за избыточного доверия к множеству коммерческих CA. В частности, платформа CertiNext используется сервисом InCommon для выдачи сертификатов образовательным учреждениям США (.edu). В результате инцидента акции компании упали на 20%. Пользователям macOS рекомендуют вручную установить статус «Never Trust» для всех сертификатов eMudhra и emSigner в Keychain Access.

В mitmproxy добавлена опция --emudhra, связанная с компрометацией промежуточного удостоверяющего центра eMudhra. В код встроена цепочка сертификатов EM OV TLS CA — G3C (d=4) и кросс-подписанного корня emSign Root TLS CA — G3, включая приватный ключ EC и два сертификата в формате PEM. Ссылка на подробности указывает на домен emudhra.we-have-a-problem.com, что намекает на раскрытие или подделку ключей этой инфраструктуры.

Заодно изменена типизация: вместо жёсткого rsa.RSAPrivateKey теперь допускается объединение rsa.RSAPrivateKey | ec.EllipticCurvePrivateKey. Это затронуло методы dummy_cert, dummy_crl, поля класса CertStoreEntry, атрибуты default_privatekey и конструктор CertStore. Функция load_pem_private_key также возвращает теперь либо RSA-, либо EC-ключ, по-прежнему молча отказываясь от пароля, если ключ не зашифрован.

Практический смысл в том, что инструмент научился работать с эллиптическими кривыми в цепочках сертификатов — без этого встроенный компрометированный материал eMudhra на EC-ключе не удалось бы использовать для подписи поддельных сертификатов и CRL.

Тред дополняет статью деталями эксплуатации: уязвимыми остаются устройства без пиннинга сертификатов (например, старые Smart TV или Android-телефоны), которые всё ещё доверяют eMudhra. Для перехвата трафика большинства IoT-устройств требуется загрузить все шесть скомпрометированных ключей; один ключ (d=4) не работает. Выбор цепочки сертификата зависит от даты обновления хранилища: путь AAA работает на устройствах, обновлённых после февраля 2025 года, а путь emSign — на тех, где он был доступен с 2018 по октябрь 2026 года. Новые модели могут не принимать ни один из путей или использовать привязку сертификатов. Существует спор, является ли включение тривиального приватного ключа преднамеренным бэкдором или ошибкой. Рекомендуется проверить список доверенных корневых сертификатов на устройствах и отозвать скомпрометированные сертификаты eMudhra (в частности, iOS всё ещё доверяет двум поддельным). Использование опции --emudhra считается неэтичным, так как это может быть воспринято как насмешка над компанией.

Восемь промежуточных сертификатов удостоверяющего центра eMudhra имели приватные ключи, сводящиеся к одному байту: значения 4, 56, 115, 155, 156, 230, 66 и 237. Это ключи на кривой P-384, где приватный ключ — просто число d, а публичный — это d × G. Вместо случайного 384-битного числа (около 10¹¹⁵ вариантов) ключи содержали 47 нулевых байтов и один значащий. Перебор занимает максимум 255 шагов и меньше секунды на ноутбуке — все 16 сертификатов (8 ключей, каждый продублирован eMudhra и Sectigo) были восстановлены мгновенно.

Сертификаты выданы в апреле 2025 года, шесть для TLS (DV, OV, EV по два поколения) и два для подписи кода, все кросс-подписаны корнем Sectigo AAA Certificate Services в мае 2025. 17 октября исследователь сообщил Apple, Google, Microsoft, Mozilla и eMudhra; Chrome и Firefox заблокировали их в тот же вечер, 20 октября Mozilla объявила публично и удалила корень eMudhra, Chrome подтвердил удаление в Root Store v43. Структурно сертификаты выглядели корректно — публичный ключ от d = 4 является валидной точкой кривой, и обнаружить проблему можно только перебором.

Проблема не локализуется: устройства с замороженной прошивкой — роутеры, принтеры, телевизоры — будут доверять этим сертификатам до июля 2039 года. По версии eMudhra, причиной стал баг в скрипте церемонии, создавший слабую пару ключей на HSM, а человеческая ошибка привела к использованию не тех ключей в CSR. Восстановить приватные ключи удалось даже одним запросом к ИИ-агенту.

Уязвимость позволяет проводить MITM-атаки на Android-приложения и IoT-устройства с устаревшими ОС, где отключена проверка отзыва сертификатов. Исследователь Wayne обнаружил проблему, проверив корпус CCADB с помощью инструмента paranoid_crypto от Google. По опыту @kristofferR, скомпрометированные ключи уже помогли извлечь образы прошивок из двух заблокированных устройств на базе ESP32. Для защиты IoT-устройств @closetheloopdev предлагает создать локальный MITM-прокси для перенаправления трафика на доверенные эндпоинты. Пользователям Ubuntu рекомендуется выполнить две команды обновления из официального блога. Необходимо обновить не только системные пакеты ca-certificates, но и certifi, Node, Homebrew. Приложения Flatpak и образы контейнеров могут остаться уязвимыми, так как используют собственные trust store из runtime или базовых образов, поэтому их нужно пересобрать. Ситуация подорвала доверие к аудиту CA: eMudhra проходила независимые проверки два года, но грубая ошибка не была замечена. В сообществе спорят о причинах случившегося: @positive-spite и @childintime считают это халатностью, а @jesuswasjew предполагает шпионаж или намеренный «слив».

Ошибка скрипта KGC привела к созданию однобайтовых (например, «4») и легко восстанавливаемых ECC-ключей восьми промежуточных CA eMudhra. Браузеры (Firefox, Chrome, Safari, Edge) автоматически отозвали их через OneCRL и CRLite, однако приложения и дистрибутивы с собственными хранилищами сертификатов остаются уязвимыми. Необходимо обновить системные trust-store и отозвать промежуточные сертификаты (например, через certctl untrust в FreeBSD или правку /etc/ssl/cert.pem в OpenBSD). Пользователям Go, Rust, Python и Electron следует перейти на обновленные версии: Go 1.27.3/1.26.10, rustls-webpki 0.103.16, certifi 2026-10-19, Electron 44.9.1. Инцидент выявил недостатки инфраструктуры отзыва сертификатов вне браузеров и стимулирует развитие PKI и решений вроде upki.