Индийский удостоверяющий центр сгенерировал приватные ключи из восьми бит, и теперь Chrome, Firefox, Safari и Edge экстренно вычищают доверие к промежуточным центрам.
История с индийским удостоверяющим центром eMudhra — это не про хакеров из голливудского блокбастера и не про утечку базы с паролями. Это про то, как несколько инженеров в апреле 2025 года нажали не ту кнопку в скрипте, и в итоге в основе мирового доверия к HTTPS-сертификатам образовалась дыра размером с футбольные ворота. Google уже отреагировала: скомпрометированные ключи заблокированы в Chrome и на Android, а корневой сертификат emSign ECC Root CA — G3 вылетает из доверенного хранилища. Если коротко — HTTPS в опасности не потому, что взломали шифрование, а потому что ключи оказались смехотворно тупыми.
Сначала о масштабе катастрофы. Восемь промежуточных сертификатов eMudhra должны были использовать эллиптическую кривую P-384 с приватным ключом из пространства примерно 2^384 значений. Это число с сотней с лишним цифр. На практике в качестве секретных ключей выступили числа 4, 56, 66, 115, 155, 156, 230 и 237. Да, восемь бит. Да, перебирается за долю секунды. Исследователь под ником Wayne обнаружил эту красоту 17 октября 2026 года, а его коллега Flüpke даже выложил на GitHub один из ключей, значение которого действительно равнялось четырём. Криптография — это сложно, но иногда она выглядит как пароль от чемодана, который забыли сменить с заводских.
Как вообще получился такой провал
В eMudhra объяснили произошедшее честно и почти по-булгаковски. Сначала система сгенерировала нормальные ключи. Потом инженеры решили протестировать экспорт через операцию wrap/unwrap. В этот момент аппаратный модуль безопасности создал второй набор ключей — уже с критически слабыми значениями. А дальше вступил человеческий фактор: метки у двух наборов были похожи, их перепутали, и в продакшен ушли именно слабые ключи. Часть сертификатов вдобавок уехала на кросс-подпись в Sectigo, так что слабые ключи оказались связаны не только с инфраструктурой eMudhra. Компания утверждает, что корневые ключи и остальные промежуточные центры не пострадали, но осадочек остался.
Почему это страшно? Обладание приватным ключом промежуточного центра позволяет выпустить действительный TLS-сертификат для чужого домена. Злоумышленник с таким документом мог бы выдать свой сервер за криптобиржу, кошелёк или любой другой сайт, а клиент бы поверил. Читать трафик, менять данные, устраивать атаки типа «человек посередине» — полный набор. По данным Google, до блокировки в публичных журналах Certificate Transparency не было записей о TLS-сертификатах, выпущенных через шесть затронутых центров. То есть либо никто не успел, либо не оставил следов. В eMudhra заявили, что только один из восьми промежуточных сертификатов вообще использовался в рабочей инфраструктуре.
Google, Mozilla, Apple и Microsoft — кто быстрее
Реакция оказалась слаженной, и это, пожалуй, единственный приятный момент во всей истории. 17 октября в 18:05 по UTC команда Chrome Root Program получила отчёт исследователя. Уже в 19:45 UTC Google выпустила обновление CRLSet, которое блокирует хеши затронутых промежуточных центров. Важная деталь: блокировка работает по SPKI, поэтому все сертификаты с этими ключами отсекаются сразу, без обновления браузера и перезапуска. На Android и Googlebook защита приехала через Google Play Services примерно в 22:00 UTC понедельника. Если устройство не получило обновление — достаточно перезагрузить его.
Mozilla не отстала: 17 октября проблемные сертификаты попали в OneCRL, защита добралась до пользователей Firefox со стандартными настройками менее чем за три часа. 20 октября вышел Firefox 158.0.1 и обновления для ESR-веток. Apple заблокировала сертификаты 19 октября, Microsoft — 20-го. Cloudflare выпустила апдейты для WARP и Cloudflare Tunnel, а также усилила защиту в CDN и сервисах Zero Trust. По данным всех четырёх вендоров, подтверждений реальных атак против пользователей нет.
Что будет дальше и почему это касается всех
Google не остановилась на точечной блокировке. Корневой сертификат emSign ECC Root CA — G3 удаляется из Chrome Root Store, массовое распространение изменения запланировано на 27 октября 2026 года. Mozilla приняла аналогичное решение для хранилища NSS. Это значит, что часть легитимных сайтов, которые до сих пор цепляются к этому корню, просто перестанет открываться в Chrome и Firefox. eMudhra пообещала работать с пострадавшими клиентами и переводить их на другие цепочки. Владельцам сайтов с сертификатами от emSign ECC Root CA — G3 нужно срочно получать новый TLS-сертификат в другой иерархии, иначе их встретит не пользователь, а ошибка безопасности.
Google также сообщила, что внимательно изучает вопрос дальнейшего присутствия остальных сертификатов eMudhra в Chrome Root Store. Учитывая серьёзность инцидента, это не пустая угроза. Корпорация напомнила, что включение в хранилище требует постоянной демонстрации технической компетентности и операционной дисциплины. В случае с eMudhra дисциплина дала сбой на этапе, где ошибиться было почти невозможно. Вся эта ситуация с HTTPS-сертификатами — напоминание: цепочка доверия в интернете держится не на магии, а на людях, которые пишут скрипты и иногда путают метки. Когда такие люди ошибаются, безобидный сайт может стать подделкой.
Хорошая новость в том, что инфраструктура отреагировала за часы, а не за недели. Certificate Transparency, CRLSet, OneCRL и Google Play Services сделали своё дело. Плохая — в том, что инцидент показал, насколько хрупка цепочка, если приватный ключ генерируется не так, как задумано. И это уже не первый и, к сожалению, не последний подобный случай.