У статті розбирається підхід команди Cloudflare до інциденту з надзвичайно слабкими проміжними ключами сертифікаційного центру eMudhra, описаний Максимом Геррейро. Йдеться про те, як компанія оперативно прибрала довіру до цих ключів у власній інфраструктурі, як шукала ознаки зловживання та як вимірювала, скільки клієнтів і далі приймають скомпрометований ланцюжок.
У чому полягала проблема з eMudhra
19 жовтня 2026 року Cloudflare дізналася, що в eMudhra було щонайменше вісім проміжних ключів з критично слабкими параметрами. Автор порівнює це з ситуацією, де від центру сертифікації чекають «комбінаційний замок» на 115 цифр, а той фактично обирає число 4. Інші сім ключів були такого ж порядку слабкості: 56, 66, 115, 155, 156, 230, 237.
Це принципово відрізняється від попередніх кейсів на кшталт DigiNotar, TÜRKTRUST чи TrustWave. У тих історіях до ключів отримували доступ обмежені групи зловмисників чи організацій, які могли випускати фальшиві сертифікати. У випадку з eMudhra будь-хто, маючи публічний сертифікат, міг практично миттєво відновити приватний проміжний ключ та видавати сертифікати на будь-які домени, які прийме незапатчений клієнт, що не примушує Certificate Transparency.
eMudhra заявила про вихід з публічного TLS бізнесу та пояснила проблему помилкою в скрипті генерації ключів, але сам скрипт на момент публікації Cloudflare не отримала. Додаткову підозру викликало те, що eMudhra спочатку підписала CRL нібито «правильним» ключем, а потім виправила його, підписавши вже слабким.
На цьому фоні Cloudflare зосередилася на двох завданнях: швидко прибрати довіру до цих ключів у своїй інфраструктурі та оцінити фактичну експлуатацію слабких ключів у мережі.
Як Cloudflare латала власну інфраструктуру
Перший блок роботи стосувався безпеки самих систем Cloudflare і сервісів клієнтів. За словами автора, усі системи з високим пріоритетом на момент написання були вже запатчені, для невеликої кількості низькоризикових кейсів залишались відкриті тікети.
Крок 1. Негайний патч для найважливіших систем
- У день виявлення інциденту почали оновлювати високоризикові системи.
- У першу чергу це були проксі Pingora, які відповідають за більшість вихідних TLS з'єднань з машин Cloudflare до origin-серверів клієнтів.
- За кілька годин Pingora було змінено так, щоб вона відхиляла ланцюжки, де використовуються слабкі проміжні ключі eMudhra.
Крок 2. Пошук усіх місць довіри до eMudhra за допомогою аналізу коду
- Паралельно Cloudflare запустила AI-асистований аналіз вихідного коду, щоб знайти всі системи, які прямо чи опосередковано довіряють проблемним ключам.
- Через чотири години команда мала повний список таких систем та початкові висновки по кожній.
- Для кожної системи створили окремий тікет із попереднім аналізом і попросили відповідні команди до кінця дня підтвердити або скоригувати висновки.
- Для систем із високим впливом вимагали негайне патчення, для систем з нижчим ризиком встановили дедлайн до кінця тижня.
Таким чином Cloudflare не обмежилася точковою зміною у Pingora, а системно пройшлася по всіх місцях, де могла залишатися довіра до eMudhra.
Як відслідковували спроби експлуатації слабких ключів
Далі команду цікавило, чи намагаються хтось реально використовувати ці слабкі ключі для перехоплення трафіку або підробки сертифікатів для доменів інших організацій.
Крок 3. Логування спроб TLS рукопотискань із підписом eMudhra
У Pingora додали логування всіх спроб, коли сервер (або потенційний зловмисник) презентує сертифікат, підписаний одним із слабких проміжних ключів eMudhra. Оскільки цей сервіс генерує переважну більшість вихідних TLS з'єднань, то будь-яка спроба «послухати» трафік Cloudflare, використовуючи слабкі ключі, мала б відобразитися у логах.
Розгортання логування закінчилося 21 жовтня.
Що показали логи
- За приблизно тиждень було зафіксовано близько 22 000 спроб рукопотискань із ланцюжком на слабкі ключі eMudhra.
- Приблизно дві третини з них припадали на тестові сайти на кшталт emudhra.we-have-a-problem.com, які згадувалися в попередньому пості Cloudflare як спосіб перевірити патчі.
- Більшість решти рукопотискань вела на origin-сервери, де, судячи з усього, самі власники встановили собі сертифікати, згенеровані на базі слабкого проміжного ключа.
- Усі рукопотискання, де було ввімкнено перевірку сертифікатів, Pingora відхиляла, тому що системи вже були оновлені.
Підозрілі 160 сертифікатів
Серед загального масиву рукопотискань близько 160 випадків виглядали особливо підозріло:
- У цих сертифікатів у полі SAN (Subject Alternative Name) були домени сторонніх організацій, які не збігалися з доменом у SNI запиту.
- Серед таких доменів траплялися назви, пов'язані з побутовими IoT пристроями.
- Ці сертифікати були створені вже після публічного розкриття слабких ключів, деякі з них мали строк дії понад два роки, що більше, ніж дозволено для публічних CA.
При цьому поведінка цих сертифікатів радше вказувала на «власні» дефолтні сертифікати серверів, а не на активну спробу перехоплення з'єднань Cloudflare:
- імена доменів у сертифікаті не збігалися з доменом, до якого звертався клієнт, тому перевірка імені хоста мала б провалитися;
- один і той самий сертифікат часто показувався з різних локацій Cloudflare, що вказує на те, що він знаходився безпосередньо на сервері, а не на окремому «прослуховуючому» вузлі на маршруті.
Автор робить висновок: прямих ознак масового перехоплення трафіку Cloudflare за допомогою слабких ключів не видно. Однак ключі очевидно почали використовувати дуже швидко після розкриття: один з підроблених сертифікатів мав дату 20 жовтня 18:19 UTC, тобто менш ніж за годину після публікації звіту в Bugzilla Mozilla.
Це не виключає сценаріїв точкового таргетованого перехоплення, де складно щось виявити без непрямих сигналів компрометації систем. Автор зазначає, що таких непрямих сигналів Cloudflare також не спостерігала.
Як Cloudflare оцінила вразливість відвідувачів
Друга половина роботи стосувалася не стільки самої інфраструктури Cloudflare, скільки клієнтських пристроїв. Завдання: зрозуміти, скільки браузерів та інших клієнтів усе ще приймають ланцюжок із проблемним проміжним сертифікатом.
Cloudflare не може напряму тестувати, чи довіряє конкретний відвідувач слабким ключам, не ризикуючи порушити реальне з'єднання. Тому команда використала непрямий метод на основі challenge pages.
Крок 4. Вимірювання через сторінки-челенджі
Challenge pages використовуються, коли Cloudflare хоче додатково перевірити клієнта (наприклад, для захисту від ботів). На частині таких сторінок команда розгорнула «проби» — два додаткові фонові запити з клієнта:
- один на ca1.cloudflarecaptcha.com;
- другий на ca2.cloudflarecaptcha.com.
Спочатку на ca1.cloudflarecaptcha.com було встановлено сертифікат, підписаний eMudhra, а на ca2.cloudflarecaptcha.com — звичайний коректний сертифікат як контроль.
Сторінка-фрейм із JavaScript запускала обидві проби, а Cloudflare реєструвала, чи вдалися ці з'єднання. Якщо клієнт успішно підключався до ca1 з eMudhra-ланцюжком, це означало, що він досі довіряє слабкому проміжному сертифікату.
Технічні зміни під час вимірювань
Протягом тижня конфігурація цих двох хостів та частка трафіку, де вмикалися проби, кілька разів змінювалися. Основні події (час за UTC):
- 23 жовтня 15:30 — контрольний хост ca2 також перевели на сертифікат eMudhra, але без SCT (signed certificate timestamps). Різниця в прийнятті між ca1 і ca2 була невеликою. Замість введення нового домену вирішили змінити вже наявний — так було швидше для платформи челенджів.
- 23 жовтня 16:30 — через несуміжну проблему платформа challenge pages була відкочена на попередню версію, проби тимчасово зникли.
- 27 жовтня 10:00 — проби повернули.
- 27 жовтня 16:37 — команда помітила, що не надсилається G3 cross-sign (посилання на сертифікат), який був невідомий частині клієнтів. Цей cross-sign додали до ланцюжків на обох хостах; з обох також прибрали SCT.
- 27 жовтня 16:49 — ca2 переключили на ланцюжок, що завершується коренем AAA Certificate Services.
- 27 жовтня 18:18 — частку challenge pages, на яких запускали проби, збільшили з 1 % до 10 % для зон неплатних клієнтів.
Через ці зміни на графіках, які наводить автор, видно «стрибки» прийняття сертифікатів, пов'язані не з реальним патченням клієнтів, а зі зміною налаштувань експерименту.
Обмеження методу вимірювання
Автор одразу зазначає важливий нюанс: трафік на challenge pages сильно перекошений. У ньому багато підозрілих (і не завжди підтверджених) ботів. Крім того, проби відправляють лише ті клієнти, які можуть виконувати JavaScript (браузери, вбудовані веб-оглядачі тощо).
Це означає, що дані не можна безпосередньо переносити на «весь інтернет», але вони дають уявлення про стан оновлення браузерів і особливо ботів.
Що показали 50 мільйонів проб
За тиждень Cloudflare зібрала приблизно 50 мільйонів пробних підключень і побачила таку картину:
- Сучасні оновлені браузери в більшості випадків уже не довіряють слабкому ланцюжку.
- Боти та старі браузери практично не оновлені і продовжують приймати сертифікати eMudhra.
- Вбудовані браузери, на кшталт Android WebView, суттєво відстають за темпами патчінгу: близько 30-40 % таких клієнтів усе ще приймають ланцюжок на eMudhra.
У перші дні (особливо протягом вихідних, попри «діру» в моніторингу, поки платформа була відкочена) був помітний рух у бік кращої безпеки. Після цього крива майже вирівнялася: масового подальшого патчення не видно.
Вплив ботів і підміна user-agent
29 жовтня близько 18:00 UTC Cloudflare розгорнула додаткову детекцію, яка виявила великий обсяг бот-трафіку з user-agent, що видавав себе за Chrome 150-154 на macOS.
На верхніх графіках (трафік без ознак бота) це могло виглядати як раптове «покращення» — ніби Chrome став краще відхиляти сертифікати eMudhra. Однак аналіз нижніх графіків (трафік із бот-сигналами) показав дзеркальне зростання прийняття в тій самій групі user-agent. Тобто зміни в даних були радше наслідком кращої класифікації ботів, а не оновлень у браузерах реальних користувачів.
Єдиним помітним винятком стала група Chrome 150-154 на Linux: там рівень прийняття слабкого ланцюжка послідовно знижувався, що узгоджується з продовженням патчінгу в цій конкретній когорті. Враховуючи змінність та ботоорієнтованість трафіку, автор оцінює цей результат як радше «навіюваний доказ», а не остаточний факт.
Розріз за мережами (ASN)
Cloudflare також подивилася на ситуацію за мережами (ASN).
Для великих провайдерів дані виявилися схожими:
- понад половина проб все ще приймає скомпрометований ланцюжок — як серед трафіку без чітких ознак ботів, так і серед трафіку, класифікованого як ботський;
- у перші дні помітні ознаки оновлень, далі тренд стає майже горизонтальним.
Попри всі застереження щодо перекосу на ботів, автор акцентує: боти — це теж програмне забезпечення, яке потребує оновлень. Якщо вважати цей зріз хоч трохи репрезентативним для практик оновлення софту загалом, картина виглядає тривожною — велика частина клієнтів залишається вразливою навіть після отримання публічної інформації про проблему.
Що робити розробникам і власникам систем
У фінальній частині розглядаються практичні кроки, які можуть зробити організації й розробники.
Крок 5. Оновити довіру до сертифікатів у своїх системах
- Потрібно переконатися, що у вашому trust store оновлені списки довірених центрів сертифікації та проміжних сертифікатів, а ланцюжок eMudhra із слабкими ключами більше не приймається.
- Для цього автор посилається на краудсорс-сайт, який веде Dennis Jackson: https://emudhra.we-have-a-problem.com/. Там зібрано інструкції для різних платформ.
- Розробникам на macOS окремо радять звернути увагу на специфічні інструкції для екосистеми Apple: https://emudhra.we-have-a-problem.com/apple.html.
Якщо ви використовуєте продукти Cloudflare на кшталт WARP або Tunnel, варто ознайомитися з попереднім блогпостом про інцидент eMudhra та розділом «what customers should do» за посиланням: https://blog.cloudflare.com/emudhra-certificate-compromise/#what-customers-should-do.
Подальші технічні кроки: динамічні trust store
Наостанок автор описує один із напрямів, у який дивиться Cloudflare після цього інциденту: прискорення механізмів відкликання та оновлення довіри до сертифікатів.
У деяких продуктах Cloudflare вже є власний механізм швидкого відкликання. Ідея полягає в тому, що trust store не має бути просто статичним списком кореневих CA, який зрідка оновлюється оновленнями ОС або браузера. Потрібен механізм швидких оновлень з урахуванням:
- відкликань сертифікатів;
- оновлення ключів для Certificate Transparency;
- виправлень помилок у проміжних ланцюжках.
У цьому контексті вказано проєкт upki як приклад підходу до більш динамічного керування довірою.
Інцидент із eMudhra показує, що вразливості в інфраструктурі ключів можуть ставати публічними та експлуатованими за лічені години. Без швидких каналів розповсюдження інформації про відкликання та без автоматизованих механізмів реагування значна частина клієнтів так і залишається вразливою, навіть коли серверна сторона (як у випадку Cloudflare) уже давно прибрала довіру до проблемних ключів.
Джерело: Maxime Guerreiro — Cloudflare Blog