Атака на jabber.ru вскрывает критическую уязвимость Cloudflare в 2026 году

🚨 Статус уязвимости: Официальное отслеживание

По состоянию на 21 января 2026 года, данная уязвимость официально зарегистрирована и отслеживается международными центрами координации безопасности:

CERT/CC (VINCE): Репорт VU#840183 (Статус: Открыт)

NotCVE: Идентификатор NotCVE-2026-0001 [1]

Оценка серьезности: CVSS 8.7 (High)

Вектор атаки: Сетевой (BGP-перехват, сетевое перехватывание)

Воздействие: Критическое (целостность домена, TLS MITM)

Техническая классификация

Уязвимость официально классифицирована согласно следующим стандартам перечисления:

CWE-1188 : Небезопасная инициализация ресурса по умолчанию (суть проблемы: Cloudflare по умолчанию использует небезопасное внедрение CAA).

CWE-693 : Сбой защитного механизма (отказ работы параметра accounturi).

CAPEC-94 : Adversary in the Middle (AiTM) (вектор атаки).

CAPEC-584 : Манипуляция маршрутами BGP (необходимое условие для атаки).

CAPEC-598 : DNS-спуфинг (альтернативный вектор манипуляции сетевым уровнем).

Аудио-обзор

[AudioOverview]

Видео-обзор

[VideoOverview]

TL;DR

Механизм

Cloudflare Universal SSL автоматически внедряет разрешающие CAA-записи, которые переопределяют пользовательские ограничения DNS, заставляя удостоверяющие центры игнорировать строгие проверки привязки к аккаунту.

Риск

Это открывает возможность для BGP-перехвата и сетевого вмешательства с целью получения несанкционированных TLS-сертификатов путем обхода параметров accounturi и validationmethods.

Прецедент

Эта конфигурация воссоздает брешь, эксплуатированную в 2023 jabber.ru MitM-атаке, когда перехваченный трафик позволил пройти валидацию домена с помощью проверки http-01.

Решение

Cloudflare должна прекратить переопределять пользовательские DNS-записи или полностью внедрить RFC 8657, чтобы ограничить выдачу сертификатов только авторизованным ACME-аккаунтом владельца домена.

🚨 ОБНОВЛЕНИЕ (январь 2026): Подтверждение из Венесуэлы и связанные события

Связанное событие: Патч обхода ACME WAF от Cloudflare (19 января) — другая уязвимость

19 января 2026 года Cloudflare раскрыла и исправила отдельную уязвимость, связанную с ACME, в логике WAF, обнаруженную исследователями безопасности FearsOff. [2]

Критическое различие: Это НЕ исправление для NotCVE-2026-0001. Cloudflare исправила ошибку реализации (обход WAF через логику ACME), но продолжает сохранять архитектурный недостаток (перезапись CAA), выявленный в этой статье. Быстрый ответ Cloudflare на уязвимость FearsOff—между октябрем 2025 и январем 2026—при молчании относительно проблемы RFC 8657 уже более года, указывает на то, что молчание является намеренным, а не техническим.

Подтверждение из утечки BGP в Венесуэле

В январе 2026 года произошла массовая утечка маршрутов BGP, затронувшая государственного оператора связи Венесуэлы (CANTV, AS8048), и об этом много писали в мировых СМИ. В анализе этого инцидента Cloudflare открыто заявила, что утечки маршрутов BGP происходят постоянно, и они всегда были частью интернета. [3]

Это признание особенно важно для понимания критичности описанной в статье проблемы безопасности. Если утечки BGP — это "обычное явление" (неважно, случайные или намеренные), то сетевой уровень не может быть доверенной основой для валидации домена.

Однако, как показано ниже, конфигурация Cloudflare Universal SSL по умолчанию активно отключает тот самый стандарт IETF (RFC 8657), который был специально разработан для предотвращения использования таких распространенных утечек BGP в качестве вектора атаки для выпуска поддельных сертификатов.

Я открыл новую дискуссию об этом противоречии с командой Cloudflare [4].

Введение: Критическая брешь в безопасности Cloudflare Universal SSL

Я обнаружил серьезную, но легко устранимую брешь в безопасности Cloudflare Universal SSL, затрагивающую миллионы пользователей. Мои попытки обсудить эту проблему напрямую с Cloudflare [5] оказались... скажем так, безуспешными.

Проблему лучше всего понять через призму MitM-атаки на jabber.ru [6], произошедшей в 2023 году. Тогда злоумышленники с государственной поддержкой смогли перехватить трафик jabber.ru на сетевом уровне. Это позволило им пройти валидацию домена с помощью проверки http-01 от Let's Encrypt и получить валидный TLS-сертификат для домена. Им не потребовалось взламывать сам сервер.

RFC 8659 и RFC 8657: объяснение стандартов CAA

Чтобы понять проблему, нужно разобраться в решении. Защита от подобных атак строится на двух стандартах IETF.

1. Базовый стандарт: RFC 8659 (CAA)

Во-первых, есть базовый стандарт CAA [7], обновляющий оригинальный [8]. Это можно назвать "доверием на уровне бренда". Он позволяет добавить в DNS запись:

Пример — базовая CAA-запись (доверие на уровне бренда)

david-osipov.vision. IN CAA 0 issue "letsencrypt.org"

Эта запись сообщает всем Удостоверяющим Центрам (CA): "Только Let's Encrypt может выпустить сертификат для моего домена."

Это хорошо, но недостаточно. Это означает, что любой, кто сможет пройти проверку Let's Encrypt, получит сертификат. Если злоумышленник перехватит ваш веб-сервер или (как в случае jabber.ru) ваш сетевой трафик, он пройдет проверку и получит валидный сертификат от вашего авторизованного CA.

2. Настоящий стандарт: RFC 8657 (Расширения ACME)

Здесь в игру вступает [9]. Опубликованный в ноябре 2019 года, он был разработан специально для предотвращения подобных атак. Это апгрейд от "доверия на уровне бренда" к "доверию на уровне процесса". Он добавляет два критических параметра: accounturi и validationmethods.

Параметр accounturi — это ваш "второй фактор".

Запись говорит: "Только Let's Encrypt, используя мой конкретный аккаунт, может выпустить сертификат для моего домена."

Пример — CAA-запись, привязывающая выдачу к ACME-аккаунту (`accounturi`)

david-osipov.vision. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/MY_ACCOUNT_ID"

Если бы такая запись была у jabber.ru, запрос злоумышленников с их собственного аккаунта Let's Encrypt был бы отклонен CA, и атака провалилась бы. Автор RFC 8657 (Hugo Landau) сам подтвердил это в своей статье Mitigating the Hetzner/Linode XMPP.ru MitM interception incident[10].

Параметр validationmethods — это ваш "щит от векторов атаки".

Этот параметр позволяет указать, каким именно способом CA разрешено валидировать ваш домен. Именно эта часть могла бы напрямую заблокировать атаку на jabber.ru.

Техническое погружение: http-01 vs. dns-01

Проверка http-01: CA просит разместить определенный файл на вашем веб-сервере по адресу http://your.domain/.well-known/acme-challenge/. Это доказывает контроль над веб-сервером, но метод уязвим к сетевому BGP-перехвату. Злоумышленникам не нужно трогать ваш сервер; им достаточно перехватить запрос CA, что и произошло с jabber.ru.

Проверка dns-01: CA просит разместить определенную TXT-запись в вашем DNS. Это доказывает контроль над DNS, который почти всегда является более безопасным и отдельным активом от веб-сервера.

Установив эту запись, вы полностью запрещаете CA использовать уязвимый метод http-01:

Пример — CAA-запись, ограничивающая методы валидации до `dns-01`

david-osipov.vision. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

accounturi

Параметр CAA, привязывающий выпуск сертификата к конкретному ACME-аккаунту (предотвращает выпуск от сторонних аккаунтов).

validationmethods

Параметр CAA, ограничивающий разрешённые методы валидации CA (например, только dns-01).

http-01

ACME-проверка по HTTP; доказывает контроль над веб-сервером, но уязвима к сетевому перехвату (BGP).

dns-01

ACME-проверка через DNS; доказывает контроль над DNS-записями и обычно более устойчива к перехватам.

Если бы у jabber.ru была хотя бы одна из этих записей RFC 8657, атака была бы обречена с самого начала.

Проблема Cloudflare: Конфликт функциональности

Теперь к сути проблемы. Как B2B Product Manager, я не вижу здесь "баг" — я вижу конфликт функциональности, где потребности (плохо спроектированной) функции продукта активно разрушают безопасность пользователя.

В чем проблема: Когда вы используете бесплатный Universal SSL от Cloudflare, Cloudflare автоматически добавляет свои CAA-записи для партнерских CA (Let's Encrypt, Google Trust Services и др.) [11]. Эти записи не используют параметры accounturi или validationmethods.

Хуже того, если вы попытаетесь добавить свою собственную защищенную CAA-запись (как те, что я показал выше), система Cloudflare видит это и говорит: "О, пользователь добавляет CAA-запись! Мне следует 'помочь' и добавить свои разрешающие записи тоже! А если записи пользователя конфликтуют с моими, я просто переопределю их, чтобы моя система работала гладко."

Итоговый DNS-ответ выглядит так:

... IN CAA 0 issue "letsencrypt.org; accounturi=.../MY_ACCOUNT_ID" (Ваша защищенная запись заменяется на...)

... IN CAA 0 issue "letsencrypt.org" (...эту. "Полезную" небезопасную запись Cloudflare)

Согласно правилам, CA может выпустить сертификат, если любая подходящая запись это разрешает. Ваша защищенная запись (1) правильно блокирует злоумышленника, но внедренная Cloudflare запись (2) заменяет вашу собственную и явно разрешает злоумышленнику провести атаку.

"Функция" Cloudflare активно и молча аннулирует стандарт безопасности IETF. Она воссоздает ту самую уязвимость, от которой пострадал jabber.ru, для миллионов пользователей.

Теперь посмотрим на практическую эксплуатацию:

Настройка: Пользователь делегирует свою проверку dns-01 через CNAME на сервер acme-dns, который он не полностью контролирует (распространенный безопасный паттерн).

Предполагаемая безопасность: Пользователь устанавливает запись accounturi, чтобы гарантировать, что только его собственный ACME-аккаунт может использовать эту делегацию.

Уязвимость Cloudflare: Cloudflare внедряет свою разрешающую запись issue "letsencrypt.org".

Атака: (Недобросовестный) администратор сервера acme-dns теперь может использовать свой собственный аккаунт Let's Encrypt, чтобы получить валидный сертификат для домена пользователя, полностью обходя "второй фактор" пользователя accounturi.

Это не только Cloudflare: Проблема "Платформа vs Провайдер"

Справедливости ради (и для академической точности), Cloudflare не единственная с этой проблемой. Это системная уязвимость любой "интегрированной платформы", которая связывает "магический" автоматический SSL с хостингом. Эта магия должна переопределять вашу безопасность, чтобы функционировать.

[ResponsiveTable]

Это показывает четкое, отраслевое разделение. "Чистые DNS-провайдеры" продают вам безопасность и контроль. "Интегрированные платформы" продают удобство, часто за счет безопасности.

Теоретический контекст: Почему это "конфликт" и инженерная дилемма

Теоретически, "правильное" решение было бы для Cloudflare просто не вмешиваться: если пользователь определяет CAA-запись, система не должна её переопределять. Однако архитектурно, это создает дилемму для "интегрированных платформ":

Если пользователь НЕ добавляет CAA-запись: Cloudflare ДОЛЖНА добавить свою, чтобы указать CA, которая будет выпускать сертификаты Universal SSL.

Если пользователь ДОБАВЛЯЕТ CAA-запись: Облегченное решение (которое использует Cloudflare) — добавить свою запись в дополнение к пользовательской. Строгое решение — уважать выбор пользователя и позволить ему полностью управлять CAA.

Cloudflare выбрала облегченный подход. Это удобнее для её инженеров, но опаснее для пользователей.

Ответ индустрии: Многоперспективное подтверждение выдачи (MPIC)

Пока многие платформы продолжали игнорировать или переопределять RFC 8657, CA/Browser Forum решил устранить основную причину на уровне валидации. В июле 2024 года Форум одобрил Баллот SC-067 v3, требующий от Удостоверяющих Центров использовать многоперспективное подтверждение выдачи (MPIC) вместо проверки с единственной локальной точки наблюдения.

Связь с Принстоном

CA/Browser Forum специально ссылается на статью Принстонского университета 2018 года Bamboozling Certificate Authorities with BGP [19] как на основную мотивацию — модель атаки, описанная там, является именно той угрозой, для смягчения которой разработан MPIC.[20]

Результаты голосования показывают необычно широкое согласие: изменение поддержали крупные эмитенты и крупные потребители платформ.

[ResponsiveTable]

График внедрения

Согласно обновленным Базовым Требованиям TLS и тексту баллота, развертывание было поэтапным:

15 сентября 2024: MPIC становится РЕКОМЕНДОВАННЫМ для всех CA.

15 марта 2025: MPIC становится ОБЯЗАТЕЛЬНЫМ (требуется минимум 2 независимые перспективы).

15 марта 2026: Требование ужесточается до минимума 3 независимых перспектив.

Почему MPIC не заменяет RFC 8657

MPIC и RFC 8657 — это дополняющие друг друга меры контроля:

[ResponsiveTable]

Кратко: MPIC значительно снижает риск BGP-атак, но это не панацея. Исследование Принстонского университета 2023 года [21]—соавторства Henry Birge-Lee—показало, что стандартные развертывания MPIC обеспечивают только около 88,6% медианной устойчивости к решительным BGP-противникам, во многом из-за расширенной поверхности атаки инфраструктуры DNS.

Это оставляет количественно определяемый разрыв в защите (~11%), который защита на сетевом уровне не может закрыть самостоятельно. Это делает защиту на уровне идентификации как RFC 8657 (привязка аккаунта) обязательной, а не опциональной, для высокоценных доменов.

Таким образом, отказ Cloudflare соблюдать accounturi и validationmethods остается значимой брешью в эшелонированной защите, даже несмотря на то, что MPIC должен устранить простейшие сетевые атаки к 2025 году.

«Постоянный» сдвиг: уход от Cloudflare

Пока Cloudflare продолжает блокировать поддержку RFC 8657, остальная индустрия фактически объявила её требованием для следующего поколения веб-безопасности.

В ноябре 2025 года рабочая группа IETF ACME официально приняла draft-ietf-acme-dns-persist-00 [22]. Этот новый черновой стандарт позволяет использовать «Постоянную валидацию DNS» — критически важную функцию для устройств IoT и мультитенантных платформ, которые не могут выполнять 90-дневные вызовы DNS.

Критически важно, что этот новый стандарт делает обязательным RFC 8657. Он требует использования параметра accounturi для привязки постоянной записи DNS к конкретному аккаунту. Без этой привязки постоянная запись станет «маркером доступа», который любой злоумышленник может переиспользовать.

Авторство этого черновика подчеркивает разделение в индустрии. Он был соавторства инженеров из Fastly и Amazon Trust Services—прямых конкурентов Cloudflare—наряду с исследователями из Crosslayer Labs. В то время как конкуренты Cloudflare активно стандартизируют использование accounturi для защиты своих платформ, продукт Universal SSL компании Cloudflare остается архитектурно несовместим с ним.

Матрица поддержки RFC 8657 (2026)

Следующая таблица показывает растущий разрыв между ориентированными на безопасность поставщиками и теми, которые приоритизируют устаревшие модели удобства.

[ResponsiveTable]

Синергия с DNSSEC

Отказ от поддержки RFC 8657 вдвойне опасен, если учесть роль DNSSEC. Как отметил исследователь Henry Birge-Lee в дискуссиях с CA/Browser Forum, комбинация CAA + DNSSEC + RFC 8657 — это единственный механизм, который позволяет выдаче сертификатов быть «полностью основанной на криптографическом доверии». [29]

"Наш криптографический дизайн DV предоставляет владельцам доменов критическую возможность декларативно защищать свои доменные имена от сетевых атак на выдачу сертификатов."

— Birge-Lee et al., «Cryptographically-Secured Domain Validation» (2024) [30]
Без accounturi, даже подписанный DNSSEC домен уязвим, если злоумышленник может перехватить трафик валидации (как видно из инцидента в Венесуэле). Поддерживая RFC 8657, владелец домена может криптографически заблокировать выдачу на конкретный ключ аккаунта. Переопределение этих записей Cloudflare фактически понижает безопасность домена, независимо от того, использует ли он DNSSEC или нет.

Но... Это действительно проблема? (Да, это так)

Инцидент с jabber.ru — это основной, мощный кейс-стади, но веб-PKI — это кладбище похожих инцидентов, для предотвращения которых были созданы эти стандарты.

3 сентября 2011 — Взлом DigiNotar: Полная компрометация CA привела к выдаче мошеннических сертификатов для Google, Yahoo и других, использовавшихся для MitM-атак на государственном уровне. [31] [32] accounturi (или даже базовый CAA) был бы защитой.

2015-2016 — WoSign и StartCom: Этим CA отказали в доверии из-за многочисленных сбоев, включая выдачу сертификатов без надлежащей валидации. [33] [32] validationmethods предотвратил бы выдачу через нестандартные, более слабые методы.

31 августа 2017 — Цепочка веб-уязвимостей: Исследователь показал, как простая уязвимость path traversal на веб-сервере может быть использована для прохождения проверки http-01. [34] Политика validationmethods=dns-01 сделала бы этот целый класс атак бесполезным.

Август 2018 — Исследование BGP-перехвата (Принстон): Фундаментальная статья Принстонского университета [19] продемонстрировала, как BGP-перехват может быть использован для обхода валидации http-01. Атака на jabber.ru была реальной реализацией этой точной модели угрозы (перехват на сетевом уровне).

Январь 2026 — утечки маршрутов в Венесуэле: Массовая утечка маршрутов, затронувшая CANTV (AS8048), показала, что проблемы с BGP остаются постоянной угрозой современного интернета. Хотя Cloudflare в данном случае связывает событие с ошибкой конфигурации, а не злонамеренным действием, это доказывает, что перехват трафика — обычное явление, делающее строгую привязку к аккаунту (защита, которую обеспечивает RFC 8657) обязательной, а не опциональной. [3]

В каждом случае accounturi или validationmethods обеспечили бы критический, превентивный уровень защиты.

Мои попытки связаться с Cloudflare

Я не первый, кто это заметил. Я разместил детальный разбор этой проблемы на форуме Cloudflare Community 20 мая 2025 года.

Вот дословная выжимка в пяти актах из того треда [5]:

Акт 1 (20 мая): Я отправляю запрос "Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA".

Акт 2 (20 июня): Член команды Cloudflare (mmalden) наконец отвечает. Они утверждают, что функция не поддерживается, потому что RFC 8657 не полностью принят (неверно) и предлагают логи Certificate Transparency в качестве альтернативы. Этот ответ помечается как "Решение".

Акт 3 (23 июня): Я публикую детальное опровержение, ссылаясь на историю Cloudflare по внедрению черновых протоколов (TLS 1.3, QUIC) за годы до финализации, и указываю, что RFC 8657 уже является предложенным стандартом. Заключаю: "Единственный логичный вывод... в том, что отказ от поддержки RFC 8657 — это бизнес-решение".

Акт 4 (20 июля):

grey: "Обожаю разговаривать сам с собой в этом треде :grinning_face:"
(Мое опровержение остается без ответа. Тег "Решение" остается на неправильном ответе.)
Акт 5 (15 августа):

Эта тема была автоматически закрыта через 2 дня после последнего ответа. Новые ответы больше не допускаются.

Критическая брешь безопасности, о которой сообщил пользователь, с 1.3 тыс. просмотров и 20 лайками, не была должным образом "решена". Она была автоматически закрыта роботом.

Чтобы привлечь к этому больше внимания, я также опубликовал статью на популярном российском техническом сайте Хабр [35] 15 июня 2025 года, которая стала лучшим постом недели. Это показывает, что сообщество понимает проблему, даже если процесс поддержки Cloudflare спроектирован так, чтобы её игнорировать.

Обновление (15 января 2026): Вслед за публичным признанием Cloudflare того, что утечки маршрутов BGP происходят постоянно, [3] в контексте инцидента в Венесуэле, я открыл новое, конкретное обсуждение на их форуме комьюнити, в котором спрашиваю, почему их SSL-продукт отключает основную защиту от этих самых утечек. Вы можете поддержать этот запрос здесь: [4].

Главное противоречие: бизнес-решение, а не техническое отставание

Член команды Cloudflare заявил, что это не уязвимость и что они будут соблюдать стандарт, "если RFC 8657 будет принят".

Этот ответ, на мой взгляд, лукав.

RFC 8657 был опубликован в ноябре 2019 года. Это стандарт уже шесть лет.

У Cloudflare есть долгая история внедрения критических протоколов безопасности, таких как TLS 1.3 [36] и QUIC [37], когда они еще были в статусе черновика.

Утверждать, что им нужно "подождать" этого стандарта, противоречит всей их инновационной культуре. Это не техническое отставание; это бизнес-решение.

Когда mmalden из команды Cloudflare ответил, они заявили, что будут соблюдать стандарт, "если RFC 8657 будет принят". Этот ответ — официально помеченный как "Решение" треда — демонстративно ложен и противоречит собственной инженерной истории Cloudflare.

Как я указал в своем опровержении команде:

Стандарт уже "принят": RFC 8657 уже является Предложенным Стандартом (Proposed Standard) на треке стандартизации IETF.

Статус "черновика" не оправдание: У Cloudflare есть долгая история внедрения протоколов за годы до их финализации.

TLS 1.3: Cloudflare анонсировала поддержку 20 сентября 2016 года, за два года до финализации RFC. [38]

QUIC: Cloudflare поддержала его 25 сентября 2018 года, почти за три года до публикации RFC. [39]

ECH: Они поддерживают его с 8 декабря 2020 года, несмотря на то, что он до сих пор в статусе черновика. [40] [41]

В своем блог-посте 2018 года о QUIC Cloudflare явно хвасталась этой культурой: "Команда системной инженерии Cloudflare имеет долгую историю инвестирования времени и усилий в тестирование новых технологий, часто до того, как эти технологии будут стандартизированы или приняты где-либо еще". [39]

Но в случае со стандартом RFC 8657, закрывающим критическую дыру в безопасности, они утверждают, что должны дождаться окончания бюрократических процедур?

Более того, команда предложила полагаться на логи Certificate Transparency (CT) как средство смягчения. Как я им объяснил, CT-логи — это инструмент обнаружения, а не предотвращения. Они предупредят вас после того, как злоумышленник уже выпустил мошеннический сертификат и перехватил ваш трафик. Это классическая слабость CWE-1188.

Это подтверждает, что отсутствие поддержки — не технический недосмотр или вопрос стандартов. Вероятно, это сознательное бизнес-решение сохранить "бесплатный" продукт уязвимым, закрывая безопасные CAA-записи за платными планами.

Что следует сделать (Решение не сложное)

Cloudflare, которая обеспечивает работу огромной части веба (по состоянию на январь 2026 г., 21.2% всех веб-сайтов, что составляет 82.1% всех веб-сайтов, у которых известен поставщик услуг обратного прокси [42], в сравнении с предыдущими отчетами о 20.4% всех сайтов с 81.6% доли рынка [43] [44]), должна сделать следующее:

[Image]

Источник: Statista — Инфографика. Больше инфографики на Statista.

Сделать Universal SSL безопасным по умолчанию: Прекратить внедрение разрешающих записей. Вместо этого внедрять ограничивающие записи с использованием accounturi для собственных внутренних ACME-аккаунтов Cloudflare. Это даст пользователям лучшее из двух миров: они защищены по умолчанию, и если они добавят свою запись accounturi, обе будут валидными (их и Cloudflare), но не запись злоумышленника.

Обеспечить полный контроль пользователя: Обновить логику DNS. Если пользователь определяет запись для letsencrypt.org, не внедрять дублирующую разрешающую запись для того же CA. Доверяйте своему пользователю. Это простое if (user_record_exists) { do_not_inject }

Быть прозрачными: Обновить документацию [11], чтобы явно объяснять это поведение переопределения и создаваемые им риски, вместо того чтобы прятать это в мелком шрифте.

Что можно сделать прямо сейчас?

Пока Cloudflare не обновит логику Universal SSL так, чтобы она уважала пользовательские параметры accounturi и validationmethods, для пользователей тарифов Free и Pro не существует способа типа «настроил и забыл», гарантирующего защиту от описанного вектора MitM-атаки.

Тем не менее, если ваша модель угроз требует строгого соблюдения RFC 8657, вы можете добиться этого, взяв выпуск сертификатов под полный контроль:

Отключите Universal SSL: Перейдите в раздел SSL/TLS > Edge Certificates в панели управления Cloudflare и нажмите Disable Universal SSL. Это критический шаг, который запрещает Cloudflare автоматически внедрять "разрешающие" CAA-записи, перекрывающие ваши политики безопасности. Внимание: Это действие немедленно отключит HTTPS на вашем сайте, если у вас нет заранее загруженного собственного сертификата (Custom Certificate) или активного расширенного сертификата (Advanced Certificate).

Загрузите собственные сертификаты (Требуется Business или Enterprise Plan): Для полного контроля вы должны самостоятельно выпускать сертификаты (например, используя Certbot/Let’s Encrypt с привязкой к вашему ACME-аккаунту) и загружать их в Cloudflare вручную.

Почему это работает: Управляя выпуском самостоятельно, вы гарантируете использование только вашего авторизованного ACME-аккаунта. В этом режиме системы Cloudflare выступают лишь хранилищем вашего сертификата и перестают вмешиваться в процесс валидации, а значит, не добавляют свои CAA-записи. Почему это работает: Управляя выпуском самостоятельно, вы гарантируете использование только вашего авторизованного ACME-аккаунта. В этом режиме системы Cloudflare выступают лишь хранилищем вашего сертификата и перестают вмешиваться в процесс валидации, а значит, не добавляют свои CAA-записи.

Требования: Функция загрузки собственных сертификатов (Custom Certificates) доступна только на тарифах Business и Enterprise. Требования: Функция загрузки собственных сертификатов (Custom Certificates) доступна только на тарифах Business и Enterprise.

Примечание про Advanced Certificate Manager (ACM): Хотя платное дополнение ACM позволяет заказывать определенные сертификаты на младших тарифах, процессом их выпуска все равно управляет Cloudflare. Следовательно, использование ACM может не защищать от автоматического перекрытия CAA-записей. Примечание про Advanced Certificate Manager (ACM): Хотя платное дополнение ACM позволяет заказывать определенные сертификаты на младших тарифах, процессом их выпуска все равно управляет Cloudflare. Следовательно, использование ACM может не защищать от автоматического перекрытия CAA-записей.

Для всех остальных (Free/Pro): Агрессивный мониторинг CT: Если переход на тариф Business невозможен, вам придется полагаться на обнаружение, а не на предотвращение. Настройте строгий мониторинг Certificate Transparency (CT) (используя инструменты вроде certstream или встроенные уведомления Cloudflare). Если вы заметите выпуск сертификата для вашего домена, который вы не инициировали (даже если он выпущен легитимным CA, например Let’s Encrypt), рассматривайте это как инцидент безопасности.

Я надеюсь, что при достаточном внимании сообщества мы сможем убедить Cloudflare закрыть эту брешь для всех, а не только для платящих клиентов.

Спасибо, что уделили время прочтению! Надеюсь, это было полезно.

🚨 Статус уязвимости: Официальное отслеживание

По состоянию на 21 января 2026 года, данная уязвимость официально зарегистрирована и отслеживается международными центрами координации безопасности:

CERT/CC (VINCE): Репорт VU#840183 (Статус: Открыт)

NotCVE: Идентификатор NotCVE-2026-0001

Оценка серьезности: CVSS 8.7 (High)

Вектор атаки: Сетевой (BGP-перехват, сетевое перехватывание)

Воздействие: Критическое (целостность домена, TLS MITM)

Техническая классификация

Уязвимость официально классифицирована согласно следующим стандартам перечисления:

CWE-1188 : Небезопасная инициализация ресурса по умолчанию (суть проблемы: Cloudflare по умолчанию использует небезопасное внедрение CAA).

CWE-693 : Сбой защитного механизма (отказ работы параметра accounturi).

CAPEC-94 : Adversary in the Middle (AiTM) (вектор атаки).

CAPEC-584 : Манипуляция маршрутами BGP (необходимое условие для атаки).

CAPEC-598 : DNS-спуфинг (альтернативный вектор манипуляции сетевым уровнем).

Аудио-обзор

Видео-обзор

TL;DR

Механизм

Cloudflare Universal SSL автоматически внедряет разрешающие CAA-записи, которые переопределяют пользовательские ограничения DNS, заставляя удостоверяющие центры игнорировать строгие проверки привязки к аккаунту.

Риск

Это открывает возможность для BGP-перехвата и сетевого вмешательства с целью получения несанкционированных TLS-сертификатов путем обхода параметров accounturi и validationmethods.

Прецедент

Эта конфигурация воссоздает брешь, эксплуатированную в 2023 jabber.ru MitM-атаке, когда перехваченный трафик позволил пройти валидацию домена с помощью проверки http-01.

Решение

Cloudflare должна прекратить переопределять пользовательские DNS-записи или полностью внедрить RFC 8657, чтобы ограничить выдачу сертификатов только авторизованным ACME-аккаунтом владельца домена.

🚨 ОБНОВЛЕНИЕ (январь 2026): Подтверждение из Венесуэлы и связанные события

Связанное событие: Патч обхода ACME WAF от Cloudflare (19 января) — другая уязвимость

19 января 2026 года Cloudflare раскрыла и исправила отдельную уязвимость, связанную с ACME, в логике WAF, обнаруженную исследователями безопасности FearsOff.

Критическое различие: Это НЕ исправление для NotCVE-2026-0001. Cloudflare исправила ошибку реализации (обход WAF через логику ACME), но продолжает сохранять архитектурный недостаток (перезапись CAA), выявленный в этой статье. Быстрый ответ Cloudflare на уязвимость FearsOff—между октябрем 2025 и январем 2026—при молчании относительно проблемы RFC 8657 уже более года, указывает на то, что молчание является намеренным, а не техническим.

Подтверждение из утечки BGP в Венесуэле

В январе 2026 года произошла массовая утечка маршрутов BGP, затронувшая государственного оператора связи Венесуэлы (CANTV, AS8048), и об этом много писали в мировых СМИ. В анализе этого инцидента Cloudflare открыто заявила, что утечки маршрутов BGP происходят постоянно, и они всегда были частью интернета.

Это признание особенно важно для понимания критичности описанной в статье проблемы безопасности. Если утечки BGP — это "обычное явление" (неважно, случайные или намеренные), то сетевой уровень не может быть доверенной основой для валидации домена.

Однако, как показано ниже, конфигурация Cloudflare Universal SSL по умолчанию активно отключает тот самый стандарт IETF (RFC 8657), который был специально разработан для предотвращения использования таких распространенных утечек BGP в качестве вектора атаки для выпуска поддельных сертификатов.

Я открыл новую дискуссию об этом противоречии с командой Cloudflare .

Введение: Критическая брешь в безопасности Cloudflare Universal SSL

Я обнаружил серьезную, но легко устранимую брешь в безопасности Cloudflare Universal SSL, затрагивающую миллионы пользователей. Мои попытки обсудить эту проблему напрямую с Cloudflare оказались... скажем так, безуспешными.

Проблему лучше всего понять через призму MitM-атаки на jabber.ru , произошедшей в 2023 году. Тогда злоумышленники с государственной поддержкой смогли перехватить трафик jabber.ru на сетевом уровне. Это позволило им пройти валидацию домена с помощью проверки http-01 от Let's Encrypt и получить валидный TLS-сертификат для домена. Им не потребовалось взламывать сам сервер.

RFC 8659 и RFC 8657: объяснение стандартов CAA

Чтобы понять проблему, нужно разобраться в решении. Защита от подобных атак строится на двух стандартах IETF.

1. Базовый стандарт: RFC 8659 (CAA)

Во-первых, есть базовый стандарт CAA , обновляющий оригинальный . Это можно назвать "доверием на уровне бренда". Он позволяет добавить в DNS запись:

Пример — базовая CAA-запись (доверие на уровне бренда)

david-osipov.vision. IN CAA 0 issue "letsencrypt.org"

Эта запись сообщает всем Удостоверяющим Центрам (CA): "Только Let's Encrypt может выпустить сертификат для моего домена."

Это хорошо, но недостаточно. Это означает, что любой, кто сможет пройти проверку Let's Encrypt, получит сертификат. Если злоумышленник перехватит ваш веб-сервер или (как в случае jabber.ru) ваш сетевой трафик, он пройдет проверку и получит валидный сертификат от вашего авторизованного CA.

2. Настоящий стандарт: RFC 8657 (Расширения ACME)

Здесь в игру вступает . Опубликованный в ноябре 2019 года, он был разработан специально для предотвращения подобных атак. Это апгрейд от "доверия на уровне бренда" к "доверию на уровне процесса". Он добавляет два критических параметра: accounturi и validationmethods.

Параметр accounturi — это ваш "второй фактор".

Запись говорит: "Только Let's Encrypt, используя мой конкретный аккаунт, может выпустить сертификат для моего домена."

Пример — CAA-запись, привязывающая выдачу к ACME-аккаунту (`accounturi`)

david-osipov.vision. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/MY_ACCOUNT_ID"

Если бы такая запись была у jabber.ru, запрос злоумышленников с их собственного аккаунта Let's Encrypt был бы отклонен CA, и атака провалилась бы. Автор RFC 8657 (Hugo Landau) сам подтвердил это в своей статье Mitigating the Hetzner/Linode XMPP.ru MitM interception incident .

Параметр validationmethods — это ваш "щит от векторов атаки".

Этот параметр позволяет указать, каким именно способом CA разрешено валидировать ваш домен. Именно эта часть могла бы напрямую заблокировать атаку на jabber.ru.

Техническое погружение: http-01 vs. dns-01

Проверка http-01: CA просит разместить определенный файл на вашем веб-сервере по адресу http://your.domain/.well-known/acme-challenge/. Это доказывает контроль над веб-сервером, но метод уязвим к сетевому BGP-перехвату. Злоумышленникам не нужно трогать ваш сервер; им достаточно перехватить запрос CA, что и произошло с jabber.ru.

Проверка dns-01: CA просит разместить определенную TXT-запись в вашем DNS. Это доказывает контроль над DNS, который почти всегда является более безопасным и отдельным активом от веб-сервера.

Установив эту запись, вы полностью запрещаете CA использовать уязвимый метод http-01:

Пример — CAA-запись, ограничивающая методы валидации до `dns-01`

david-osipov.vision. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

accounturi

Параметр CAA, привязывающий выпуск сертификата к конкретному ACME-аккаунту (предотвращает выпуск от сторонних аккаунтов).

validationmethods

Параметр CAA, ограничивающий разрешённые методы валидации CA (например, только dns-01).

http-01

ACME-проверка по HTTP; доказывает контроль над веб-сервером, но уязвима к сетевому перехвату (BGP).

dns-01

ACME-проверка через DNS; доказывает контроль над DNS-записями и обычно более устойчива к перехватам.

Если бы у jabber.ru была хотя бы одна из этих записей RFC 8657, атака была бы обречена с самого начала.

Проблема Cloudflare: Конфликт функциональности

Теперь к сути проблемы. Как B2B Product Manager, я не вижу здесь "баг" — я вижу конфликт функциональности, где потребности (плохо спроектированной) функции продукта активно разрушают безопасность пользователя.

В чем проблема: Когда вы используете бесплатный Universal SSL от Cloudflare, Cloudflare автоматически добавляет свои CAA-записи для партнерских CA (Let's Encrypt, Google Trust Services и др.) . Эти записи не используют параметры accounturi или validationmethods.

Хуже того, если вы попытаетесь добавить свою собственную защищенную CAA-запись (как те, что я показал выше), система Cloudflare видит это и говорит: "О, пользователь добавляет CAA-запись! Мне следует 'помочь' и добавить свои разрешающие записи тоже! А если записи пользователя конфликтуют с моими, я просто переопределю их, чтобы моя система работала гладко."

Итоговый DNS-ответ выглядит так:

... IN CAA 0 issue "letsencrypt.org; accounturi=.../MY_ACCOUNT_ID" (Ваша защищенная запись заменяется на...)

... IN CAA 0 issue "letsencrypt.org" (...эту. "Полезную" небезопасную запись Cloudflare)

Согласно правилам, CA может выпустить сертификат, если любая подходящая запись это разрешает. Ваша защищенная запись (1) правильно блокирует злоумышленника, но внедренная Cloudflare запись (2) заменяет вашу собственную и явно разрешает злоумышленнику провести атаку.

"Функция" Cloudflare активно и молча аннулирует стандарт безопасности IETF. Она воссоздает ту самую уязвимость, от которой пострадал jabber.ru, для миллионов пользователей.

Теперь посмотрим на практическую эксплуатацию:

Настройка: Пользователь делегирует свою проверку dns-01 через CNAME на сервер acme-dns, который он не полностью контролирует (распространенный безопасный паттерн).

Предполагаемая безопасность: Пользователь устанавливает запись accounturi, чтобы гарантировать, что только его собственный ACME-аккаунт может использовать эту делегацию.

Уязвимость Cloudflare: Cloudflare внедряет свою разрешающую запись issue "letsencrypt.org".

Атака: (Недобросовестный) администратор сервера acme-dns теперь может использовать свой собственный аккаунт Let's Encrypt, чтобы получить валидный сертификат для домена пользователя, полностью обходя "второй фактор" пользователя accounturi.

Это не только Cloudflare: Проблема "Платформа vs Провайдер"

Справедливости ради (и для академической точности), Cloudflare не единственная с этой проблемой. Это системная уязвимость любой "интегрированной платформы", которая связывает "магический" автоматический SSL с хостингом. Эта магия должна переопределять вашу безопасность, чтобы функционировать.

[ResponsiveTable]

Это показывает четкое, отраслевое разделение. "Чистые DNS-провайдеры" продают вам безопасность и контроль. "Интегрированные платформы" продают удобство, часто за счет безопасности.

Теоретический контекст: Почему это "конфликт" и инженерная дилемма

Теоретически, "правильное" решение было бы для Cloudflare просто не вмешиваться: если пользователь определяет CAA-запись, система не должна её переопределять. Однако архитектурно, это создает дилемму для "интегрированных платформ":

Если пользователь НЕ добавляет CAA-запись: Cloudflare ДОЛЖНА добавить свою, чтобы указать CA, которая будет выпускать сертификаты Universal SSL.

Если пользователь ДОБАВЛЯЕТ CAA-запись: Облегченное решение (которое использует Cloudflare) — добавить свою запись в дополнение к пользовательской. Строгое решение — уважать выбор пользователя и позволить ему полностью управлять CAA.

Cloudflare выбрала облегченный подход. Это удобнее для её инженеров, но опаснее для пользователей.

Ответ индустрии: Многоперспективное подтверждение выдачи (MPIC)

Пока многие платформы продолжали игнорировать или переопределять RFC 8657, CA/Browser Forum решил устранить основную причину на уровне валидации. В июле 2024 года Форум одобрил Баллот SC-067 v3, требующий от Удостоверяющих Центров использовать многоперспективное подтверждение выдачи (MPIC) вместо проверки с единственной локальной точки наблюдения.

Связь с Принстоном

CA/Browser Forum специально ссылается на статью Принстонского университета 2018 года Bamboozling Certificate Authorities with BGP как на основную мотивацию — модель атаки, описанная там, является именно той угрозой, для смягчения которой разработан MPIC.

Результаты голосования показывают необычно широкое согласие: изменение поддержали крупные эмитенты и крупные потребители платформ.

[ResponsiveTable]

График внедрения

Согласно обновленным Базовым Требованиям TLS и тексту баллота, развертывание было поэтапным:

15 сентября 2024: MPIC становится РЕКОМЕНДОВАННЫМ для всех CA.

15 марта 2025: MPIC становится ОБЯЗАТЕЛЬНЫМ (требуется минимум 2 независимые перспективы).

15 марта 2026: Требование ужесточается до минимума 3 независимых перспектив.

Почему MPIC не заменяет RFC 8657

MPIC и RFC 8657 — это дополняющие друг друга меры контроля:

[ResponsiveTable]

Кратко: MPIC значительно снижает риск BGP-атак, но это не панацея. Исследование Принстонского университета 2023 года —соавторства Henry Birge-Lee—показало, что стандартные развертывания MPIC обеспечивают только около 88,6% медианной устойчивости к решительным BGP-противникам, во многом из-за расширенной поверхности атаки инфраструктуры DNS.

Это оставляет количественно определяемый разрыв в защите (~11%), который защита на сетевом уровне не может закрыть самостоятельно. Это делает защиту на уровне идентификации как RFC 8657 (привязка аккаунта) обязательной, а не опциональной, для высокоценных доменов.

Таким образом, отказ Cloudflare соблюдать accounturi и validationmethods остается значимой брешью в эшелонированной защите, даже несмотря на то, что MPIC должен устранить простейшие сетевые атаки к 2025 году.

«Постоянный» сдвиг: уход от Cloudflare

Пока Cloudflare продолжает блокировать поддержку RFC 8657, остальная индустрия фактически объявила её требованием для следующего поколения веб-безопасности.

В ноябре 2025 года рабочая группа IETF ACME официально приняла draft-ietf-acme-dns-persist-00 . Этот новый черновой стандарт позволяет использовать «Постоянную валидацию DNS» — критически важную функцию для устройств IoT и мультитенантных платформ, которые не могут выполнять 90-дневные вызовы DNS.

Критически важно, что этот новый стандарт делает обязательным RFC 8657. Он требует использования параметра accounturi для привязки постоянной записи DNS к конкретному аккаунту. Без этой привязки постоянная запись станет «маркером доступа», который любой злоумышленник может переиспользовать.

Авторство этого черновика подчеркивает разделение в индустрии. Он был соавторства инженеров из Fastly и Amazon Trust Services—прямых конкурентов Cloudflare—наряду с исследователями из Crosslayer Labs. В то время как конкуренты Cloudflare активно стандартизируют использование accounturi для защиты своих платформ, продукт Universal SSL компании Cloudflare остается архитектурно несовместим с ним.

Матрица поддержки RFC 8657 (2026)

Следующая таблица показывает растущий разрыв между ориентированными на безопасность поставщиками и теми, которые приоритизируют устаревшие модели удобства.

[ResponsiveTable]

Синергия с DNSSEC

Отказ от поддержки RFC 8657 вдвойне опасен, если учесть роль DNSSEC. Как отметил исследователь Henry Birge-Lee в дискуссиях с CA/Browser Forum, комбинация CAA + DNSSEC + RFC 8657 — это единственный механизм, который позволяет выдаче сертификатов быть «полностью основанной на криптографическом доверии».

"Наш криптографический дизайн DV предоставляет владельцам доменов критическую возможность декларативно защищать свои доменные имена от сетевых атак на выдачу сертификатов."

— Birge-Lee et al., «Cryptographically-Secured Domain Validation» (2024)
Без accounturi, даже подписанный DNSSEC домен уязвим, если злоумышленник может перехватить трафик валидации (как видно из инцидента в Венесуэле). Поддерживая RFC 8657, владелец домена может криптографически заблокировать выдачу на конкретный ключ аккаунта. Переопределение этих записей Cloudflare фактически понижает безопасность домена, независимо от того, использует ли он DNSSEC или нет.

Но... Это действительно проблема? (Да, это так)

Инцидент с jabber.ru — это основной, мощный кейс-стади, но веб-PKI — это кладбище похожих инцидентов, для предотвращения которых были созданы эти стандарты.

3 сентября 2011 — Взлом DigiNotar: Полная компрометация CA привела к выдаче мошеннических сертификатов для Google, Yahoo и других, использовавшихся для MitM-атак на государственном уровне. accounturi (или даже базовый CAA) был бы защитой.

2015-2016 — WoSign и StartCom: Этим CA отказали в доверии из-за многочисленных сбоев, включая выдачу сертификатов без надлежащей валидации. validationmethods предотвратил бы выдачу через нестандартные, более слабые методы.

31 августа 2017 — Цепочка веб-уязвимостей: Исследователь показал, как простая уязвимость path traversal на веб-сервере может быть использована для прохождения проверки http-01. Политика validationmethods=dns-01 сделала бы этот целый класс атак бесполезным.

Август 2018 — Исследование BGP-перехвата (Принстон): Фундаментальная статья Принстонского университета продемонстрировала, как BGP-перехват может быть использован для обхода валидации http-01. Атака на jabber.ru была реальной реализацией этой точной модели угрозы (перехват на сетевом уровне).

Январь 2026 — утечки маршрутов в Венесуэле: Массовая утечка маршрутов, затронувшая CANTV (AS8048), показала, что проблемы с BGP остаются постоянной угрозой современного интернета. Хотя Cloudflare в данном случае связывает событие с ошибкой конфигурации, а не злонамеренным действием, это доказывает, что перехват трафика — обычное явление, делающее строгую привязку к аккаунту (защита, которую обеспечивает RFC 8657) обязательной, а не опциональной.

В каждом случае accounturi или validationmethods обеспечили бы критический, превентивный уровень защиты.

Мои попытки связаться с Cloudflare

Я не первый, кто это заметил. Я разместил детальный разбор этой проблемы на форуме Cloudflare Community 20 мая 2025 года.

Вот дословная выжимка в пяти актах из того треда :

Акт 1 (20 мая): Я отправляю запрос "Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA".

Акт 2 (20 июня): Член команды Cloudflare (mmalden) наконец отвечает. Они утверждают, что функция не поддерживается, потому что RFC 8657 не полностью принят (неверно) и предлагают логи Certificate Transparency в качестве альтернативы. Этот ответ помечается как "Решение".

Акт 3 (23 июня): Я публикую детальное опровержение, ссылаясь на историю Cloudflare по внедрению черновых протоколов (TLS 1.3, QUIC) за годы до финализации, и указываю, что RFC 8657 уже является предложенным стандартом. Заключаю: "Единственный логичный вывод... в том, что отказ от поддержки RFC 8657 — это бизнес-решение".

Акт 4 (20 июля):

grey: "Обожаю разговаривать сам с собой в этом треде :grinning_face:"
(Мое опровержение остается без ответа. Тег "Решение" остается на неправильном ответе.)
Акт 5 (15 августа):

Эта тема была автоматически закрыта через 2 дня после последнего ответа. Новые ответы больше не допускаются.

Критическая брешь безопасности, о которой сообщил пользователь, с 1.3 тыс. просмотров и 20 лайками, не была должным образом "решена". Она была автоматически закрыта роботом.

Чтобы привлечь к этому больше внимания, я также опубликовал статью на популярном российском техническом сайте Хабр 15 июня 2025 года, которая стала лучшим постом недели. Это показывает, что сообщество понимает проблему, даже если процесс поддержки Cloudflare спроектирован так, чтобы её игнорировать.

Обновление (15 января 2026): Вслед за публичным признанием Cloudflare того, что утечки маршрутов BGP происходят постоянно, в контексте инцидента в Венесуэле, я открыл новое, конкретное обсуждение на их форуме комьюнити, в котором спрашиваю, почему их SSL-продукт отключает основную защиту от этих самых утечек. Вы можете поддержать этот запрос здесь: .

Главное противоречие: бизнес-решение, а не техническое отставание

Член команды Cloudflare заявил, что это не уязвимость и что они будут соблюдать стандарт, "если RFC 8657 будет принят".

Этот ответ, на мой взгляд, лукав.

RFC 8657 был опубликован в ноябре 2019 года. Это стандарт уже шесть лет.

У Cloudflare есть долгая история внедрения критических протоколов безопасности, таких как TLS 1.3 и QUIC , когда они еще были в статусе черновика.

Утверждать, что им нужно "подождать" этого стандарта, противоречит всей их инновационной культуре. Это не техническое отставание; это бизнес-решение.

Когда mmalden из команды Cloudflare ответил, они заявили, что будут соблюдать стандарт, "если RFC 8657 будет принят". Этот ответ — официально помеченный как "Решение" треда — демонстративно ложен и противоречит собственной инженерной истории Cloudflare.

Как я указал в своем опровержении команде:

Стандарт уже "принят": RFC 8657 уже является Предложенным Стандартом (Proposed Standard) на треке стандартизации IETF.

Статус "черновика" не оправдание: У Cloudflare есть долгая история внедрения протоколов за годы до их финализации.

TLS 1.3: Cloudflare анонсировала поддержку 20 сентября 2016 года, за два года до финализации RFC.

QUIC: Cloudflare поддержала его 25 сентября 2018 года, почти за три года до публикации RFC.

ECH: Они поддерживают его с 8 декабря 2020 года, несмотря на то, что он до сих пор в статусе черновика.

В своем блог-посте 2018 года о QUIC Cloudflare явно хвасталась этой культурой: "Команда системной инженерии Cloudflare имеет долгую историю инвестирования времени и усилий в тестирование новых технологий, часто до того, как эти технологии будут стандартизированы или приняты где-либо еще".

Но в случае со стандартом RFC 8657, закрывающим критическую дыру в безопасности, они утверждают, что должны дождаться окончания бюрократических процедур?

Более того, команда предложила полагаться на логи Certificate Transparency (CT) как средство смягчения. Как я им объяснил, CT-логи — это инструмент обнаружения, а не предотвращения. Они предупредят вас после того, как злоумышленник уже выпустил мошеннический сертификат и перехватил ваш трафик. Это классическая слабость CWE-1188.

Это подтверждает, что отсутствие поддержки — не технический недосмотр или вопрос стандартов. Вероятно, это сознательное бизнес-решение сохранить "бесплатный" продукт уязвимым, закрывая безопасные CAA-записи за платными планами.

Что следует сделать (Решение не сложное)

Cloudflare, которая обеспечивает работу огромной части веба (по состоянию на январь 2026 г., 21.2% всех веб-сайтов, что составляет 82.1% всех веб-сайтов, у которых известен поставщик услуг обратного прокси , в сравнении с предыдущими отчетами о 20.4% всех сайтов с 81.6% доли рынка ), должна сделать следующее:

Источник: Statista — Инфографика. Больше инфографики на Statista.

Сделать Universal SSL безопасным по умолчанию: Прекратить внедрение разрешающих записей. Вместо этого внедрять ограничивающие записи с использованием accounturi для собственных внутренних ACME-аккаунтов Cloudflare. Это даст пользователям лучшее из двух миров: они защищены по умолчанию, и если они добавят свою запись accounturi, обе будут валидными (их и Cloudflare), но не запись злоумышленника.

Обеспечить полный контроль пользователя: Обновить логику DNS. Если пользователь определяет запись для letsencrypt.org, не внедрять дублирующую разрешающую запись для того же CA. Доверяйте своему пользователю. Это простое if (user_record_exists) { do_not_inject }

Быть прозрачными: Обновить документацию , чтобы явно объяснять это поведение переопределения и создаваемые им риски, вместо того чтобы прятать это в мелком шрифте.

Что можно сделать прямо сейчас?

Пока Cloudflare не обновит логику Universal SSL так, чтобы она уважала пользовательские параметры accounturi и validationmethods, для пользователей тарифов Free и Pro не существует способа типа «настроил и забыл», гарантирующего защиту от описанного вектора MitM-атаки.

Тем не менее, если ваша модель угроз требует строгого соблюдения RFC 8657, вы можете добиться этого, взяв выпуск сертификатов под полный контроль:

Отключите Universal SSL: Перейдите в раздел SSL/TLS > Edge Certificates в панели управления Cloudflare и нажмите Disable Universal SSL. Это критический шаг, который запрещает Cloudflare автоматически внедрять "разрешающие" CAA-записи, перекрывающие ваши политики безопасности. Внимание: Это действие немедленно отключит HTTPS на вашем сайте, если у вас нет заранее загруженного собственного сертификата (Custom Certificate) или активного расширенного сертификата (Advanced Certificate).

Загрузите собственные сертификаты (Требуется Business или Enterprise Plan): Для полного контроля вы должны самостоятельно выпускать сертификаты (например, используя Certbot/Let’s Encrypt с привязкой к вашему ACME-аккаунту) и загружать их в Cloudflare вручную.

Почему это работает: Управляя выпуском самостоятельно, вы гарантируете использование только вашего авторизованного ACME-аккаунта. В этом режиме системы Cloudflare выступают лишь хранилищем вашего сертификата и перестают вмешиваться в процесс валидации, а значит, не добавляют свои CAA-записи. Почему это работает: Управляя выпуском самостоятельно, вы гарантируете использование только вашего авторизованного ACME-аккаунта. В этом режиме системы Cloudflare выступают лишь хранилищем вашего сертификата и перестают вмешиваться в процесс валидации, а значит, не добавляют свои CAA-записи.

Требования: Функция загрузки собственных сертификатов (Custom Certificates) доступна только на тарифах Business и Enterprise. Требования: Функция загрузки собственных сертификатов (Custom Certificates) доступна только на тарифах Business и Enterprise.

Примечание про Advanced Certificate Manager (ACM): Хотя платное дополнение ACM позволяет заказывать определенные сертификаты на младших тарифах, процессом их выпуска все равно управляет Cloudflare. Следовательно, использование ACM может не защищать от автоматического перекрытия CAA-записей. Примечание про Advanced Certificate Manager (ACM): Хотя платное дополнение ACM позволяет заказывать определенные сертификаты на младших тарифах, процессом их выпуска все равно управляет Cloudflare. Следовательно, использование ACM может не защищать от автоматического перекрытия CAA-записей.

Для всех остальных (Free/Pro): Агрессивный мониторинг CT: Если переход на тариф Business невозможен, вам придется полагаться на обнаружение, а не на предотвращение. Настройте строгий мониторинг Certificate Transparency (CT) (используя инструменты вроде certstream или встроенные уведомления Cloudflare). Если вы заметите выпуск сертификата для вашего домена, который вы не инициировали (даже если он выпущен легитимным CA, например Let’s Encrypt), рассматривайте это как инцидент безопасности.

Я надеюсь, что при достаточном внимании сообщества мы сможем убедить Cloudflare закрыть эту брешь для всех, а не только для платящих клиентов.

Спасибо, что уделили время прочтению! Надеюсь, это было полезно.

References

Cloudflare Community (2025) Critical security gap: Cloudflare must fully support RFC 8657 CAA. Cloudflare Community. Retrieved from https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999.

ValdikSS (2023) Encrypted traffic interception on Hetzner and Linode targeting the largest russian XMPP (Jabber) messaging service. Retrieved from https://notes.valdikss.org.ru/jabber.ru-mitm/.

Hallam-Baker, P., Stradling, R., Hoffman-Andrews, J. (2019) DNS certification authority authorization (CAA) resource record. RFC Editor. Retrieved from https://doi.org/10.17487/RFC8659.

Rescorla, E. (2018) The transport layer security (TLS) protocol version 1.3. RFC Editor. Retrieved from https://doi.org/10.17487/RFC8446.

Iyengar, J., Thomson, M. (2021) QUIC: A UDP-based multiplexed and secure transport. RFC Editor. Retrieved from https://doi.org/10.17487/RFC9000.

Hallam-Baker, P., Stradling, R. (2013) DNS certification authority authorization (CAA) resource record. RFC Editor. Retrieved from https://doi.org/10.17487/RFC6844.

Landau, H. (2019) Certification authority authorization (CAA) record extensions for account URI and automatic certificate management environment (ACME) method binding. RFC Editor. Retrieved from https://doi.org/10.17487/RFC8657.

Landau, H. (2023) XMPP CA/jabber.ru incident. Retrieved from https://www.devever.net/~hl/xmpp-incident.

Let's Encrypt (n.d.) Challenge types - Let's encrypt documentation. Let's Encrypt. Retrieved from https://letsencrypt.org/docs/challenge-types/.

Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J., Mittal, P. (2018) Bamboozling certificate authorities with BGP. USENIX Association. Retrieved from https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee.

Cloudflare (n.d.) Add CAA records - Cloudflare SSL/TLS docs. Cloudflare. Retrieved from https://developers.cloudflare.com/ssl/edge-certificates/caa-records/.

Cloudflare Community (2025) Cloudflare nameservers ignore CAA record validationmethods and accounturi. Cloudflare Community. Retrieved from https://community.cloudflare.com/t/cloudflare-nameservers-ignore-caa-record-validationmethods-and-accounturi/758109.

Vercel (n.d.) Working with DNS. Vercel. Retrieved from https://vercel.com/docs/domains/working-with-dns.

AWS (n.d.) Set up to use AWS certificate manager. AWS. Retrieved from https://docs.aws.amazon.com/acm/latest/userguide/setup.html#setup-caa.

Google Cloud (n.d.) Troubleshoot certificate issuance - Google cloud. Google Cloud. Retrieved from https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#caa.

DNSimple Support (2025) CAA record format and policy tags. DNSimple Support. Retrieved from https://support.dnsimple.com/articles/caa-record-format/.

AWS (2017) Amazon route 53 now supports CAA records. AWS. Retrieved from https://aws.amazon.com/about-aws/whats-new/2017/08/amazon-route-53-now-supports-caa-records/.

Wikipedia (n.d.) DigiNotar - Wikipedia. Wikipedia. Retrieved from https://en.wikipedia.org/wiki/DigiNotar.

SSLMate (n.d.) Timeline of certificate authority failures. SSLMate. Retrieved from https://sslmate.com/resources/certificate_authority_failures.

Gualtieri, M. (2017) Chaining remote web vulnerabilities to abuse let's encrypt. Retrieved from https://www.mike-gualtieri.com/posts/chaining-remote-web-vulnerabilities-to-abuse-lets-encrypt.

Осипов, Д. (2025) Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023. Retrieved from https://habr.com/ru/articles/918570/.

Cloudflare Blog (2024) Avoiding downtime: Modern alternatives to outdated certificate pinning practices. Retrieved from https://blog.cloudflare.com/why-certificate-pinning-is-outdated/.

Laudian (2025) Cloudflare nameservers ignore CAA record... (workaround). Cloudflare Community. Retrieved from https://community.cloudflare.com/t/cloudflare-nameservers-ignore-caa-record-validationmethods-and-accounturi/758109/2.

Birge-Lee, H., Cimaszewski, G. H., Krahenbuhl, C., Wang, L., Gable, A., Mittal, P. (2024) Cryptographically-secured domain validation. Retrieved from https://secure-certificates.princeton.edu/cryptographic-domain-validation.pdf.

Cimaszewski, G., Birge-Lee, H., Wang, L., Rexford, J., Mittal, P. (2023) How effective is multiple-vantage-point domain control validation?. Retrieved from https://doi.org/10.48550/arXiv.2302.08000.

Let's Encrypt (2023) Certificate authority authorization (CAA) - Let's encrypt documentation. Let's Encrypt. Retrieved from https://letsencrypt.org/docs/caa/.

Wilson, K. (2016) Distrusting new wosign and startcom certificates. Retrieved from https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/.

CA/Browser Forum (2024) Ballot sc067v3: Require domain validation and CAA checks to be performed from multiple network perspectives. CA/Browser Forum. Retrieved from https://cabforum.org/2024/08/05/ballot-sc067v3-require-domain-validation-and-caa-checks-to-be-performed-from-multiple-network-perspectives-corroboration.

Sullivan, N. (2016) Introducing TLS 1.3. Retrieved from https://blog.cloudflare.com/introducing-tls-1-3/.

Jones, N. (2018) Get a head start with QUIC. Retrieved from https://blog.cloudflare.com/head-start-with-quic/.

Heurich, S., Birge-Lee, H., Slaughter, M. (2025) Automated certificate management environment (ACME) challenge for persistent DNS TXT record validation (draft-ietf-acme-dns-persist-00). IETF. Retrieved from https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/.

Birge-Lee, H. (2025) The use of DNSSEC by certificate authorities. Server Certificate WG (CA/B Forum). Retrieved from https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/WNGFxQjPkPY.

DigiCert (2025) A new DNS validation method for simplified certificate automation. Retrieved from https://www.digicert.com/blog/a-new-dns-validation-method.

Let's Encrypt Community Support (2023) Issue certificates only to specific agent keys. Let's Encrypt Community Support. Retrieved from https://community.letsencrypt.org/t/issue-certificates-only-to-specific-agent-keys/184283.

Netlify Support Forums (2023) Let's encrypt accounturi for CAA record. Netlify Support Forums. Retrieved from https://answers.netlify.com/t/lets-encrypt-accounturi-for-caa-record/103453.

Google Chrome (2025) Chrome root program policy, version 1.7. Google Chrome. Retrieved from https://googlechrome.github.io/chromerootprogram/.

Google Trust Services LLC (2025) Google trust services, certification practice statement v.5.22. Google Trust Services LLC. Retrieved from https://pki.goog/repo/cps/5.22/GTS-CPS.html.

Rescorla, E., Oku, K., Sullivan, N., Wood, C. A. (2025) TLS encrypted client hello. Internet Engineering Task Force. Retrieved from https://datatracker.ietf.org/doc/draft-ietf-tls-esni/25/.

Patton, C. (2020) Good-bye ESNI, hello ECH!. Retrieved from https://blog.cloudflare.com/encrypted-client-hello/.

Gaudiaut, T. (2025) Cloudflare, a hidden pillar of the internet. Statista. Retrieved from https://www.statista.com/chart/35487/market-share-of-reverse-proxy-services-cloudflare/.

W3Techs.com (2025) Usage of reverse proxy services for websites, november 2025. W3Techs. Retrieved from https://w3techs.com/technologies/overview/proxy/.

W3Techs (2026) Cloudflare — W3techs reverse proxy services usage statistics. W3Techs. Retrieved from https://w3techs.com/technologies/details/cn-cloudflare.

Herdes, B. (2026) A closer look at a BGP anomaly in venezuela. Retrieved from https://blog.cloudflare.com/bgp-route-leak-venezuela/.

Cloudflare Community (2026) Universal SSL exposes domains to BGP leaks (re: Venezuela analysis). Cloudflare Community. Retrieved from https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930.

Netlify (2023) HTTPS (SSL) | netlify docs. Netlify. Retrieved from https://docs.netlify.com/domains-https/https-ssl/#netlify-managed-certificates.

Let's Encrypt Community Support (2022) PROD support for rfc8657 CAA constraints. Let's Encrypt Community Support. Retrieved from https://community.letsencrypt.org/t/prod-support-for-rfc8657-caa-constraints-for-accounturi-and-validationmethods/181584.

University of North Carolina at Charlotte (2024) Let's encrypt using accounturi. University of North Carolina at Charlotte. Retrieved from https://acme-lecaa.charlotte.edu/.

Google Cloud (n.d.) Use Google-managed SSL certificates. Google Cloud. Retrieved from https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#caa.

NotCVE.org (2026) Notcve-2026-0001 — Cloudflare universal SSL CAA augmentation. NotCVE.org. Retrieved from https://notcve.org/view.php?id=NotCVE-2026-0001.

Carnegie Mellon University CERT/CC (2026) CERT/CC VINCE case VU#840183. Carnegie Mellon University CERT/CC. Retrieved from https://kb.cert.org/vince/view/840183.

Deshpande, H., Mitchell, A., Garofalo, L. (2026) How we mitigated a vulnerability in Cloudflare's ACME validation logic. Retrieved from https://blog.cloudflare.com/acme-path-vulnerability/.