Mozilla, Google і Apple блокують eMudhra через катастрофічно слабкі ключі

Mozilla, Google, Apple та Microsoft екстрено заблокували вісім проміжних сертифікатів eMudhra після того, як дослідник виявив, що їхні приватні ключі були згенеровані з катастрофічно низькою ентропією. Формально це були ключі P-384, але фактичні значення приватних параметрів виявилися меншими за 256 — тобто замість астрономічного простору пошуку зловмиснику достатньо було перевірити максимум кілька сотень варіантів.

Один із скомпрометованих ключів, що належав EM OV TLS CA - G3C, мав приватне значення 4. Дослідник Flüpke опублікував його як доказ, а BleepingComputer незалежно підтвердив відповідність ключа відкликаному сертифікату.

Для проміжного центру сертифікації це особливо небезпечно. Той, хто володіє його приватним ключем, потенційно може самостійно підписувати сертифікати для чужих доменів. Якщо клієнт довіряє такому CA і не має додаткових механізмів перевірки, підроблений сертифікат може використовуватися для видавання атакуючого сервера за справжній сайт і перехоплення HTTPS-трафіку. Mozilla та Google прямо назвали ключі скомпрометованими.

Помилка пережила дві аудиторські перевірки

Вразливі проміжні CA були створені ще 30 квітня 2025 року під час формальної Key Generation Ceremony. eMudhra стверджує, що генерація виконувалася на сертифікованих HSM рівня FIPS 140-2 Level 3, тобто проблема полягала не у відсутності апаратного захисту.

За попередньою версією компанії, під час процедури wrap/unwrap поряд із правильними сильними ключами утворився другий набір слабких ключів. Саме слабкі ключі врешті опинилися в опублікованих проміжних CA. Точну першопричину eMudhra поки ще розслідує.

Особливо незручно для компанії виглядає те, що проблема залишалася непоміченою близько 18 місяців і пережила два незалежні аудиторські цикли. Ієрархія була присутня у браузерних trust stores приблизно з середини 2025 року.

eMudhra також заявила, що її інфраструктуру не зламували й витоку даних не було. За версією компанії, проблема виникла саме під час процедури створення ключів, а не внаслідок зовнішнього компрометування HSM або серверів.

Вісім сертифікатів і кілька типів довіри

Проблема зачепила вісім intermediate CA. Шість із них призначалися для TLS — по два для DV, OV та EV-сертифікатів, ще два використовувалися для code signing. Частину сертифікатів також було cross-signed через Sectigo, що ускладнило відкликання довіри в різних trust stores. Bugzilla

Дослідник під ніком Wayne повідомив про проблему 17 жовтня. Він надав докази контролю над усіма вісьмома приватними ключами. Mozilla змогла незалежно відтворити відновлення ключів менш ніж за дві години після отримання повідомлення, не знаючи методу дослідника, що підтвердило тривіальність атаки.

У Firefox блокування через OneCRL було розгорнуто того ж дня менш ніж за три години після отримання повідомлення. Для більшості користувачів не знадобилося ані оновлення браузера, ані перезапуск. Mozilla додатково випустила Firefox 158.0.1 та оновлення ESR для систем, де Remote Settings могли бути вимкнені політиками.

Chrome відреагував ще раніше: Google отримав повідомлення о 18:05 UTC 17 жовтня й до 19:45 UTC уже розгорнув CRLSet, який блокує ключі за їхнім SPKI. Завдяки цьому блок поширився не лише на конкретні сертифікати, а й на інші сертифікати з тими самими публічними ключами.

Certificate Transparency суттєво знизив ризик для браузерів

Є й важливий позитивний момент.

Google перевірив Certificate Transparency logs і не знайшов жодного TLS-сертифіката, підписаного шістьма скомпрометованими TLS intermediate CA до моменту їх блокування. Це означає, що підроблений сертифікат, створений через ці ключі, не міг би пройти стандартну перевірку в сучасному Chrome, який вимагає CT для публічно довірених сертифікатів.

eMudhra також заявляє, що сім із восьми проміжних CA взагалі не використовувалися у production, а єдиний активний не встиг видати жодного end-entity сертифіката. Компанія посилається і на власну перевірку, і на публічні дані Certificate Transparency.

Втім, це не означає, що проблему можна вважати суто теоретичною. Не всі TLS-клієнти вимагають CT, а далеко не кожна програма оперативно отримує списки відкликаних сертифікатів.

Браузери захищені швидше, ніж серверне ПЗ

Саме тут починається друга частина проблеми.

Firefox і Chrome можуть оперативно доставляти власні revocation lists, але багато мов програмування, пакетних менеджерів, CLI-інструментів і серверних застосунків покладаються на локальні CA bundles. Для них проблема зникає лише після оновлення пакета, trust store або самого runtime.

Через інцидент уже вийшли або готуються оновлення для великої кількості компонентів. Серед них:

• Go 1.27.3 та 1.26.10;
• NSS 3.131.1;
• Python certifi 2026.10.19;
• pip 26.2.2;
• uv 0.13.4;
• Rust rustls-webpki 0.103.16;
• webpki-roots 1.0.10;
• Electron 44.9.1, 43.8.1 та 42.11.16;
• Alpine Linux ca-certificates 20261020-r0;
• Homebrew ca-certificates;
• оновлені пакети Ubuntu.

Для Debian, Node.js, Bun та деяких інших компонентів на момент публікації виправлення ще перебували в роботі.

Особливий випадок — програми, що використовують системні trust stores або власні копії CA bundles без повноцінної перевірки відкликання. Mozilla окремо оновила NSS і прибрала root, під яким знаходилися проблемні intermediate CA, саме для захисту таких застосунків.

Google видаляє кореневий сертифікат eMudhra

Google пішов далі простого блокування восьми ключів.

Компанія вирішила прибрати emSign ECC Root CA – G3 із Chrome Root Store. Саме цей root підписував скомпрометовані проміжні CA. Розгортання видалення для всіх клієнтів Chrome Root Store заплановане на 27 жовтня, а в Canary та Beta воно має з’явитися раніше.

Це вже матиме наслідки й для легітимних сертифікатів, які використовують цю ієрархію. Google прямо рекомендує власникам сайтів із сертифікатами, що ланцюжаться до emSign ECC Root CA - G3, терміново перейти на іншу PKI-ієрархію.

Chrome Root Program також переглядає подальшу присутність інших сертифікатів eMudhra у своєму root store. Google пояснює це серйозністю інциденту та вимогами до операційної дисципліни CA.

eMudhra зі свого боку повідомляє, що недовіра до ECC root зачіпає один клієнтський ecosystem у США й компанія вже переводить його на іншу публічно довірену PKI-ієрархію. За твердженням eMudhra, глобальний TLS-бізнес становить близько 1% її виручки, хоча репутаційний ефект компанія визнає складним для оцінки.

P-384 належить до стандартних еліптичних кривих і передбачає приватний параметр із величезного простору можливих значень. Безпечність тут базується саме на тому, що цей параметр генерується криптографічно випадково.

Якщо ж генератор створює значення менше 256, увесь захист фактично зникає: атакуючому достатньо перебрати від 1 до 255, для кожного кандидата обчислити відповідний публічний ключ і порівняти його з відомим сертифікатом.

Тобто проблема була не в тому, що сам алгоритм P-384 виявився слабким. Слабким виявився процес генерації ключів, який перетворив криптографічний простір у набір із кількох сотень чисел. Саме тому Mozilla змогла самостійно відновити ключі практично одразу після повідомлення. ʼ

Найдивніше в цій історії навіть не те, що один приватний ключ дорівнював 4, а те, що такі ключі змогли пройти формальну Key Generation Ceremony, роботу з HSM, публікацію в глобальній WebPKI та два наступні аудиторські цикли.

eMudhra пообіцяла опублікувати повний root-cause analysis після завершення розслідування та переглянути процедури генерації ключів, зокрема проблемний етап wrap/unwrap.

Нагадаємо, PHP готує екстрене оновлення через дві критичні вразливості з оцінкою 9,2 CVSS.