Слабые ключи в цепочке доверия TLS — проблема не только Cloudflare и не только сайтов, чьи сертификаты выданы eMudhra. Если приложение доверяет одному из скомпрометированных промежуточных сертификатов, злоумышленник может создать сертификат для любого домена и выдать себя за его сервер. Это открывает возможность перехватывать или изменять трафик; алгоритмы шифрования TLS при этом не взломаны.
Повод проверить собственную инфраструктуру появился после сообщения Cloudflare Security о компрометации закрытых ключей восьми промежуточных сертификатов eMudhra. Их доверяли браузеры, операционные системы и сервисы Cloudflare. Компания сообщила, что не обнаружила активной эксплуатации проблемы в своих сервисах, но это не подтверждает безопасность сторонних приложений и серверов.
Риск может быть незаметен при обычной работе сайта: соединение устанавливается, а ошибка проверки сертификата не появляется. Проблема проявляется там, где конкретный клиент использует уязвимый путь проверки — например, собственное хранилище доверия или встроенную в приложение TLS-библиотеку. Поэтому успешная проверка в браузере сама по себе не доказывает, что защищены фоновые службы, API-клиенты и соединения с origin-сервером.
В статье разобраны механика угрозы и границы уже принятых мер Cloudflare, а также проверки для администраторов: какие сертификаты и хранилища доверия пересмотреть, как обновить зависимости и контейнеры и почему после исправления важно не отключать проверку сертификатов. Практический критерий — не просто отсутствие ошибки в браузере, а корректная проверка сертификата тем приложением, которое устанавливает соединение.
Почему слабый ключ превращает доверенный сертификат в угрозу
Подделка проходит проверку цепочки доверия
Cloudflare сообщила о компрометации закрытых ключей, связанных с промежуточными сертификатами eMudhra. Такой сертификат подписывает сертификаты для сайтов, а его ключ подтверждает право выпускать их от имени центра сертификации. Если закрытый ключ попал к посторонним, тот может создать сертификат для чужого домена и подписать его скомпрометированным ключом.
Клиент проверяет не только имя сайта, но и цепочку подписей до доверенного корневого центра. Пока промежуточный сертификат считается доверенным, поддельный сертификат может пройти эту проверку: для клиента он выглядит как выданный легитимным участником WebPKI. Злоумышленник, способный направить соединение через свою инфраструктуру, может предъявить такой сертификат и перехватывать или изменять трафик.
Уязвимость — в ключе, а не в TLS
Это не взлом алгоритмов шифрования TLS. Протокол может работать штатно: он устанавливает защищённое соединение с узлом, подлинность которого клиент ошибочно принимает. Слабость или утечка ключа подрывает проверку личности сервера, а не шифрование канала как таковое.
Риск зависит от того, принимает ли конкретная система затронутую цепочку и может ли атакующий оказаться на пути соединения. Отзыв сертификата или обновление списка доверия помогает лишь клиентам, которые получают и применяют эти изменения. Поэтому браузерная проверка сама по себе не доказывает, что тот же сертификат отклонит серверное приложение с отдельным или встроенным хранилищем доверия.
Кого затрагивает компрометация сертификатов eMudhra
Cloudflare сообщила о компрометации закрытых ключей, связанных с восемью промежуточными сертификатами eMudhra. Риск не ограничен пользователями Cloudflare: он касается систем, которые доверяют этим сертификатам через WebPKI и могут принять выпущенный с их помощью сертификат за подлинный.
Доверие зависит от хранилища сертификатов
Промежуточный сертификат связывает корневой центр сертификации с сертификатами сайтов. Если его закрытый ключ скомпрометирован, злоумышленник может создать сертификат для домена, которому доверяет соответствующая цепочка. Уязвимым становится не конкретный сайт, а клиент, который строит цепочку до доверенного корня и не отклоняет сертификат по другим проверкам.
- Браузеры и операционные системы. Они используют собственные или системные хранилища доверия. Если цепочка принимается, браузер может установить TLS-соединение без обычного предупреждения о недоверенном сертификате.
- Серверные приложения и сетевые сервисы. Они могут опираться на системное хранилище, отдельный набор доверенных центров или встроенные сертификаты. Поэтому два приложения на одном устройстве способны по-разному оценить одну и ту же цепочку.
- Системы с пользовательскими хранилищами доверия. Если в них явно добавлены промежуточные сертификаты или корни, поведение может отличаться от стандартной проверки в браузере.
Компрометация не означает, что каждый клиент уже получил поддельный сертификат или что любой TLS-сеанс можно перехватить. Для атаки нужно, чтобы клиент принял соответствующую цепочку, а злоумышленник смог направить соединение через контролируемую им точку. Но проверка только в браузере не подтверждает безопасность остальных приложений: они могут использовать другой trust store и иначе обрабатывать отзыв сертификатов.
Cloudflare выпустила обновления своих клиентов и развернула меры для собственных сервисов. Это снижает риск в затронутых компонентах Cloudflare, но не обновляет автоматически хранилища доверия браузеров, операционных систем и сторонних приложений.
Что Cloudflare уже обновила и где защита включается автоматически
Cloudflare выпустила обновления для Cloudflare One Client, также известного как WARP или приложение 1.1.1.1, и для Cloudflare Tunnel (cloudflared). Они предназначены для устранения уязвимых путей в соответствующих клиентах. Это не обновляет автоматически сторонние приложения, серверы или системные хранилища доверия.
Обновления клиентов и сервисов
- Cloudflare One Client: Android —
v2.5.6, iOS —v1.12.16, Windows, macOS и Linux —2026.8.2115.0. - Приложение 1.1.1.1: Android —
v6.38.10, iOS —v6.31.7, Windows, macOS и Linux —2026.8.2115.0. - Cloudflare Tunnel: обновление до
2026.10.2.
На момент публикации обновление Cloudflare One Agent для iOS ещё проходило проверку App Store. Наличие новой версии для других платформ не означает, что она уже установлена на каждом устройстве: это нужно проверить отдельно.
Меры на стороне Cloudflare
Cloudflare также применила меры для CDN и серверной части Zero Trust. По хронологии компании, обновления клиентов и WARP были опубликованы 20 октября, обновление cloudflared — позднее в тот же день, а меры для CDN и серверного Zero Trust были полностью развёрнуты вечером. Компания узнала о компрометации накануне, 19 октября, и начала оценку ситуации.
Для Gateway автоматическая защита зависит от актуального клиента: обновлённый Cloudflare One Client применяет защиту в соответствующем клиентском сценарии. Если трафик проходит через другое приложение, собственный TLS-стек или отдельное хранилище доверия, меры Cloudflare не заменяют обновление этих компонентов. Обновление сервиса на стороне Cloudflare и обновление клиента — разные действия; одно не подтверждает, что другое выполнено.
Почему браузер может быть защищён, а приложение — нет
У разных программ разные хранилища доверия
Браузер и приложение могут проверять один и тот же TLS-сертификат по разным цепочкам доверия. Браузеры обычно используют системное хранилище сертификатов или собственный набор доверенных центров. Приложение же может обращаться к системному хранилищу, поставлять собственный набор корневых сертификатов или использовать TLS-библиотеку со встроенными сертификатами. Поэтому обновление браузера или системы не обязательно меняет то, чему доверяет конкретное приложение.
Отдельный случай — корпоративные клиенты и приложения с пользовательским хранилищем доверия. Администратор мог добавить туда сертификат промежуточного центра или настроить собственную цепочку. Такая конфигурация не обязательно совпадает с общесистемной и может продолжить принимать сертификат, который браузер уже отклоняет.
Отзыв сертификата не одинаково быстро доходит до всех клиентов
Узнав о компрометации ключей промежуточных сертификатов eMudhra, Cloudflare обновила свои клиенты и применила меры на своей стороне. Но отзыв сертификата сам по себе не гарантирует немедленного отказа во всех приложениях: клиент должен получить и проверить актуальные данные об отзыве, а его библиотека — поддерживать соответствующий механизм. Некоторые приложения используют кэшированные сведения или иначе обрабатывают ошибки проверки.
Успешное открытие сайта в браузере подтверждает только то, что проверку прошёл этот браузер по своему пути доверия. Оно не доказывает, что те же сертификаты и правила проверки использует приложение на том же устройстве.
Проверять нужно фактический TLS-клиент, которым пользуется сервис: его хранилище доверия, настройки проверки цепочки и обработку отзыва. Если приложение подключается через отдельный агент или библиотеку, результат браузерного теста не характеризует этот путь.
Какие настройки TLS и сертификаты проверить на origin-сервере
Компрометация затрагивает не только клиентские приложения. Проверьте и конфигурации, которые сами устанавливают доверие к сертификатам: пользовательские хранилища доверия для mTLS и настройки Origin TLS. Важно выяснить, какие сертификаты и центры сертификации разрешены именно в этих конфигурациях, а не полагаться на системное хранилище по умолчанию.
Пользовательские хранилища доверия для mTLS
Если origin использует mTLS, проверьте заданный вручную trust store: какие CA в него добавлены и остаются ли они необходимыми. Удалите скомпрометированные сертификаты eMudhra, если они присутствуют в этом хранилище и используются для проверки клиентских сертификатов. Такая проверка важна и тогда, когда системное хранилище уже обновлено: приложение или сервер может продолжать доверять отдельному набору CA.
Режимы Origin TLS и собственные сертификаты
Для конфигураций Origin TLS в режимах Full (strict) или Strict проверьте сертификат, который предъявляет origin, и цепочку, по которой его проверяет Cloudflare. Убедитесь, что на сервере установлен ожидаемый сертификат, а его доверенная цепочка не опирается на скомпрометированный промежуточный сертификат. Если для origin настроен собственный сертификат или отдельный CA, проверьте их актуальность и состав цепочки: пользовательская конфигурация может отличаться от публичного хранилища доверия.
Обновление клиентских библиотек не меняет автоматически сертификаты на origin и пользовательские trust stores. Это отдельные части TLS-конфигурации, их нужно проверять независимо.
Как обновить зависимости, контейнеры и TLS-проверку приложения
Обновление WARP или cloudflared не обновляет автоматически библиотеки и хранилища доверия в вашем приложении. Если оно проверяет TLS самостоятельно, уязвимый путь может сохраниться внутри зависимости, базового образа или встроенного набора корневых сертификатов.
Проверьте, откуда приложение берёт TLS-компоненты
- Изучите дерево зависимостей и найдите библиотеки, которые устанавливают TLS-соединения или проверяют сертификаты. Обновите их до исправленных версий, доступных для вашего стека.
- Проверьте trust store: приложение может использовать системное хранилище, собственный файл сертификатов или набор, встроенный в библиотеку. Обновление операционной системы не обязательно затронет два последних варианта.
- Если зависимости входят в контейнер, обновите их в исходной сборке и пересоберите образ. Обновление пакетов на хосте не меняет уже собранный образ.
После обновления перезапустите затронутые процессы
Уже запущенный процесс может продолжать использовать загруженную библиотеку или старое хранилище сертификатов. После обновления перезапустите приложение и пересоздайте контейнеры; если образ развёртывается через оркестратор или CI/CD, выполните новый deploy, а не ограничивайтесь изменением исходного файла.
Отдельно проверьте код и настройки TLS-клиента. Вызовы, отключающие проверку сертификата или имени узла, не устраняют проблему: они убирают защиту от подмены сервера. Не заменяйте ими обновление зависимостей и trust store. Если после обновления соединение завершается ошибкой сертификата, выясните, какой компонент выполняет проверку и какое хранилище он фактически использует; не подавляйте ошибку без проверки цепочки доверия.
Какие версии Cloudflare One и cloudflared закрывают известные уязвимые пути
Cloudflare выпустила обновления для Cloudflare One Client — приложения, также известного как WARP или 1.1.1.1 app, — и для Cloudflare Tunnel, то есть cloudflared. Минимальные версии различаются по продукту и платформе: проверьте, какое именно приложение установлено, а не ориентируйтесь только на название WARP.
Минимальные версии клиентов
- Cloudflare One Client: Android —
v2.5.6; iOS —v1.12.16; Windows Desktop, macOS и Linux —2026.8.2115.0. - Приложение 1.1.1.1: Android —
v6.38.10; iOS —v6.31.7; Windows Desktop, macOS и Linux —2026.8.2115.0. - Cloudflare Tunnel: обновите
cloudflaredдо2026.10.2.
Для iOS есть оговорка: обновление Cloudflare One Agent на момент публикации ещё проходило проверку App Store. Это относится именно к Cloudflare One Agent; в источнике отдельно указана версия приложения 1.1.1.1 для iOS.
Публикация обновлений и серверные меры
Cloudflare узнала о компрометации ключей промежуточных сертификатов eMudhra 19 октября 2026 года примерно в 17:00 UTC и начала оценку. Обновления Cloudflare One Client и WARP появились 20 октября в 02:00 UTC, а обновление cloudflared — в 09:15 UTC. К 19:20 UTC того же дня Cloudflare полностью развернула меры для CDN и серверной части Zero Trust.
Эти отметки показывают ход реакции Cloudflare, но не подтверждают, что сторонние приложения или системы получили исправления. Для собственного парка устройств и туннелей важна фактически установленная версия: публикация обновления не означает, что клиент уже обновился.
Что проверить сегодня: путь проверки сертификата в реальном приложении
Проверка должна повторять путь, которым приложение устанавливает TLS-соединение. Браузер, системная служба и приложение могут использовать разные библиотеки и хранилища доверия. Поэтому успешное открытие сайта в браузере или тест через curl не подтверждают, что остальные компоненты проверяют сертификаты так же.
Проверьте фактический путь проверки
Определите, какие приложения и службы устанавливают TLS-соединения с затронутыми доменами. Для каждого выясните, какой TLS-клиент и trust store он использует: системный, встроенный в приложение или заданный отдельно.
Сверьте версии клиентских библиотек и обновления хранилищ доверия. Если компонент использует собственный trust store, обновление операционной системы или браузера может его не затронуть.
Проверьте соединение именно из приложения и среды, где оно работает: с теми же настройками TLS, прокси и проверкой имени узла. Успешный запрос из другой среды подтверждает только её собственный путь проверки.
Обновите затронутые библиотеки и trust stores, затем пересоберите контейнеры, если они содержат старые зависимости или сертификаты. Перезапустите службу или выполните redeploy: уже запущенный процесс может продолжать использовать загруженное ранее хранилище.
Изучите ошибки проверки сертификатов после обновления. Не отключайте проверку цепочки или имени узла, чтобы убрать ошибку: это не устраняет проблему доверия, а позволяет приложению принять неподтверждённый сертификат.
Результат теста относится только к проверенному клиенту, его trust store и конкретному TLS-маршруту. Защиту остальных приложений нужно подтверждать отдельно.
