Showing all 1 blog posts

Blog Navigation Instructions

КибербезопасностьБрифинг

CVE-2026-14440: как Cloudflare Universal SSL обходит строгие CAA-ограничения RFC 8657

••
Поверженный раненый рыцарь в доспехах держит большой щит с логотипом Cloudflare, пробитый пулей.

Метаданные для печати

Информация о документе

Версия:
2.2
Опубликовано:
Изменено:
Язык:
RU
Цифровой идентификатор объекта (DOI):
10.5281/zenodo.21261469
Лицензия:
CC BY 4.0

Сведения об авторах

Автор:

Академические идентификаторы

ISNI:
0000 0005 1802 960X
ORCID:
0009-0005-2713-9242
VIAF:
139173726847611590332
ResearcherID:
LPQ-0554-2024

Базы знаний

Wikidata:
Q130604188

Прочие идентификаторы

Google Scholar:
ZCoKxAQAAAAJ
MusicBrainz:
345819dd-e878-4a1a-8544-e3c75a110e4f
LinkedIn:
david-osipov
GitHub:
DavidOsipov

Информация для цитирования

Стиль APA

Osipov, D. (2025) CVE-2026-14440: как Cloudflare Universal SSL обходит строгие CAA-ограничения RFC 8657. Доступно по адресу https://doi.org/10.5281/zenodo.21261469.

BibLaTeX

              @article{osipov-2025-cve-2026-14440-cloudflare-univer2025-12-31,
  author = {David Osipov},
  author+an:orcid = {1="https://orcid.org/0009-0005-2713-9242"},
  author+an:isni = {1="https://isni.org/isni/000000051802960X"},
  author+an:wikidata = {1="https://www.wikidata.org/wiki/Q130604188"},
  author+an:viaf = {1="https://viaf.org/viaf/139173726847611590332"},
  title = {CVE-2026-14440: как Cloudflare Universal SSL обходит строгие CAA-ограничения RFC 8657},
  date = {2025-12-31},
  doi = {10.5281/zenodo.21261469},
  url = {https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/}
}

Аннотация

В этой статье анализируется CVE-2026-14440, ранее отслеживавшаяся как NotCVE-2026-0001: уязвимость Cloudflare Universal SSL / CAA / RFC 8657, при которой авторитетный DNS Cloudflare может на момент запроса отдавать автоматически управляемый CAA RRset, перекрывающий CAA-записи владельца домена. В результате защиты RFC 8657 через accounturi и validationmethods не применяются сквозно на затронутых зонах Universal SSL. Если домен полагается на эти CAA-ограничения, он остаётся подверженным этому сценарию, пока остаётся в уязвимом режиме автоматического управления CAA в Universal SSL. Успешная эксплуатация нетривиальна: атакующему нужен ACME-аккаунт в одном из центров сертификации из отдаваемого CAA RRset, и ему нужно пройти проверку контроля домена сразу с нескольких географически независимых сетевых точек, используемых в Multi-Perspective Issuance Corroboration (MPIC). Если эти условия выполнены, эксплуатация может привести к выдаче TLS-сертификата, которому доверяют браузеры, и атаке посредника против затронутого домена.

Предыстория

Расследование началось, когда я попытался усилить домены на Cloudflare с помощью CAA-ограничений RFC 8657 и обнаружил, что Universal SSL не сохраняет ожидаемые защиты accounturi и validationmethods в наборе CAA-записей, который видят центры сертификации. Первый публичный отчёт был подан через Cloudflare Community Security forum, где проблему сначала восприняли как ограничение продукта. Затем я сохранил исследовательский след через NotCVE, публичные технические разборы, публичные архивы и координированное раскрытие через CISA/CERT/CC VINCE. Ключевое уточнение было таким: уязвимость не сводится к тому, что Cloudflare выбирает центр сертификации. Сбой в том, что автоматически управляемый CAA RRset Universal SSL может помешать центру сертификации увидеть пользовательские ограничения RFC 8657 на момент запроса. В ходе координации я помог уточнить фактически отдаваемое поведение CAA, влияние на accounturi и validationmethods, оценку серьёзности, практические ограничения опубликованного обходного пути и то, почему Certificate Transparency является обнаружением, а не предотвращением. В итоге Cloudflare как CNA присвоила и опубликовала CVE-2026-14440, указав Давида Осипова как независимого исследователя.

Развернуть вопросы и ответы об уязвимости, рисках, реалистичном атакующем, снижении риска и истории раскрытия

Часто задаваемые вопросы о CVE-2026-14440, Cloudflare Universal SSL, CAA и RFC 8657

  1. Что такое CVE-2026-14440?

    CVE-2026-14440 — это уязвимость Cloudflare Universal SSL / CAA / RFC 8657. На затронутых зонах Universal SSL авторитетный DNS Cloudflare может на момент запроса отдавать автоматически управляемый CAA RRset, который перекрывает CAA-записи владельца домена. В результате ограничения RFC 8657 accounturi или validationmethods не применяются сквозно.

  2. Это означает, что Cloudflare взломали?

    Нет. Это не взлом Cloudflare. Публичные записи не подтверждают активную эксплуатацию против клиентов Cloudflare. В истории изменений NVD видно, что CISA-ADP изменила значение SSVC exploitation с none на poc; это поддерживает формулировку «есть доказательство концепции», но не утверждение, что атаки уже идут. Это сбой защитного механизма: автоматическое управление CAA в Universal SSL конфликтует с пользовательскими CAA-ограничениями RFC 8657.

  3. Кого это затрагивает?

    Затронутый продукт — Cloudflare Universal SSL в облачном сервисе Cloudflare. Практический риск прежде всего важен для владельцев зон, которые хотят полноценную предотвращающую защиту от несанкционированного выпуска сертификатов через RFC 8657 accounturi и/или validationmethods, пока Universal SSL остаётся включённым.

  4. Кто может реалистично воспользоваться этой уязвимостью?

    Реалистичный атакующий — это сетевой актор, а не обычный веб-злоумышленник. Ему нужен ACME-аккаунт в одном из центров сертификации из отдаваемого CAA RRset, и он должен пройти проверку контроля домена с нескольких географически независимых сетевых точек, используемых в MPIC. На практике это указывает на государственного или терпимого государством сетевого актора, крупного провайдера или транзитного оператора, либо на сложного BGP/маршрутного атакующего с достаточно широким контролем, чтобы повлиять на несколько точек проверки.

  5. Делает ли MPIC эту уязвимость неважной?

    Нет. MPIC — важное улучшение: он резко повышает барьер атаки, особенно против локальных BGP-перехватов из одной сетевой точки. Но это не полноценная замена привязке к ACME-аккаунту и методу проверки по RFC 8657. Исследование Princeton/USENIX 2023 года показало 88% медианной устойчивости для изученной multi-vantage-схемы Let’s Encrypt против 76% у проверки из одной точки, а работа Princeton/IMC 2025 года показала, что оптимальные MPIC-развёртывания предотвращали ошибочную выдачу сертификата более чем в 87% оцененных реальных BGP-перехватов. Это сильное снижение риска, но не математическая гарантия. Остаточный риск зависит от развёртывания MPIC у конкретного CA, расположения точек проверки, правил кворума, DNS-пути, RPKI и реального поведения маршрутизации.

  6. Чему остаётся подвержен затронутый домен?

    Если зона полагается на ограничения RFC 8657 accounturi или validationmethods, но остаётся в уязвимом режиме автоматического управления CAA в Universal SSL, эти ограничения не защищают выпуск сертификатов сквозно. Эксплуатация всё равно нетривиальна: атакующему нужен ACME-аккаунт в одном из центров сертификации из отдаваемого CAA RRset, и он должен пройти проверку контроля домена сразу с нескольких географически независимых сетевых точек, используемых в MPIC. Если эти условия выполнены, возможна выдача TLS-сертификата, которому доверяют браузеры, и атака посредника против затронутого домена.

  7. Зачем нужны accounturi и validationmethods?

    RFC 8657 позволяет владельцу домена ограничить выпуск сертификатов конкретным ACME-аккаунтом через accounturi и/или конкретными методами проверки через validationmethods. Эти механизмы усложняют несанкционированный выпуск сертификатов, если атакующий способен вмешаться в проверку контроля домена.

  8. Какая предотвращающая мера действительно убирает этот сценарий?

    Полноценная предотвращающая защита от этого сценария требует использовать релевантные механизмы RFC 8657 — accounturi и/или validationmethods — так, чтобы центр сертификации действительно видел их в фактически отдаваемом CAA RRset. На затронутом пути Cloudflare это означает уйти из автоматического управления CAA в Universal SSL: отключить Universal SSL на затронутой зоне только после того, как уже активен другой действующий сертификат на стороне Cloudflare.

  9. Можно ли просто отключить Universal SSL?

    Небезопасно, если заранее не активен другой действующий сертификат на стороне Cloudflare. Документация Cloudflare предупреждает, что отключение Universal SSL удаляет сертификат Universal SSL из сети Cloudflare, а новые TLS-соединения будут падать, если другого действующего сертификата нет.

  10. Полная защита бесплатна для клиентов Free и Pro?

    Публичная документация Cloudflare не показывает бесплатного и бесшовного предотвращающего пути для клиентов Free и Pro, которые хотят полноценную защиту от этой уязвимости при сохранении HTTPS через затронутый путь сертификатов Cloudflare. Advanced Certificates требуют платного дополнения Advanced Certificate Manager; Cloudflare указывает, что они позволяют выбрать центр сертификации и предпочитаемый метод проверки. Загруженные Custom Certificates предназначены для клиентов Business и Enterprise, а не Free или Pro. Поэтому реалистичные варианты такие: заплатить за подходящий путь сертификатов Cloudflare, например Advanced Certificate Manager / Advanced Certificates; сменить тариф или архитектуру; уйти из затронутого режима Universal SSL; перейти к провайдеру, который сохраняет RFC 8657 accounturi / validationmethods в фактически отдаваемом CAA RRset без отдельной платной надстройки; либо принять остаточный риск с мониторингом CT только как средством обнаружения.

  11. Мониторинг Certificate Transparency исправляет проблему?

    Нет. Мониторинг CT — это видимость после выпуска, а не предотвращающий контроль. Он может показать, что сертификат существует, но не останавливает CA до выпуска, не закрывает короткое окно для MITM-атаки и не сообщает автоматически, является ли сертификат злонамеренным или обычной платформенной автоматикой. В документации Cloudflare CT Monitoring указано, что alerts по умолчанию выключены, а обычный выпуск сертификатов, backup certificates и shared certificates могут создавать уведомления. RFC 6962 прямо говорит, что CT-логи сами по себе не предотвращают ошибочную выдачу сертификатов.

  12. Почему в статье всё ещё упоминается jabber.ru?

    Инцидент jabber.ru 2023 года — это прецедент класса атак: ошибочный выпуск сертификата через перехват проверки контроля домена. Это не инцидент Cloudflare и не прямой прогноз эксплуатации против зон Cloudflare с anycast, но он показывает, почему привязка к ACME-аккаунту и методу проверки по RFC 8657 важна.

  13. Какие официальные оценки серьёзности указаны в публичных записях?

    Публичные записи показывают CNA CVSS v4.0 7.6 High и CISA-ADP CVSS v3.1 6.8 Medium. NVD сейчас помечает запись как Awaiting Enrichment и пока не дала собственную расширенную оценку.

  14. Означает ли значение CISA-ADP SSVC 'poc', что атака уже идёт?

    Нет. В терминах SSVC значение poc означает уровень «доказательство концепции» и сигнал для приоритизации реагирования. Это не публичное доказательство активной эксплуатации против клиентов Cloudflare. В статье нельзя утверждать подтверждённую эксплуатацию в реальных атаках без прямого публичного источника.

  15. Кто обнаружил и сообщил об уязвимости?

    Публичная запись NVD указывает Давида Осипова как независимого исследователя. Раскрытие координировалось через CISA/CERT/CC VINCE, а финальную CVE-запись Cloudflare опубликовала в своей зоне ответственности CNA.

  16. Что должны проверить затронутые клиенты?

    Нужно проверять фактически отдаваемый CAA RRset через DNS-запросы, а не только CAA-записи, видимые в панели управления Cloudflare. Важно то, какой набор CAA-записей видит центр сертификации в момент проверки.

Эта проблема теперь официально опубликована как CVE-2026-14440 [1b] [2b]. Более ранний идентификатор NotCVE-2026-0001 сохранён как исторический, потому что он связывает до-CVE исследовательский след, архивы и историю раскрытия.

Публичные записи нужно читать внимательно: оценка CNA по CVSS v4.0 составляет 7.6 High, тогда как CISA-ADP указывает 6.8 Medium по CVSS v3.1. NVD пока не опубликовала собственную расширенную оценку и помечает запись как Awaiting Enrichment [2c]. Текущая публичная классификация CWE — [7].

Клиенты, которым требуется строгое применение RFC 8657, должны выйти из затронутого пути автоматического управления CAA в Universal SSL, причём делать это нужно только после того, как уже активен другой действующий Cloudflare edge certificate. Мониторинг Certificate Transparency остаётся важным, но это видимость после выпуска: он может выявить ошибочную выдачу сертификата постфактум, но не предотвратить сам выпуск [5b] [6b].

TL;DR

Механизм

Cloudflare Universal SSL может сделать не ту CAA-политику той, которая реально имеет значение.

Владелец домена может опубликовать строгие ограничения RFC 8657 для CAA — accounturi и/или validationmethods, — но на затронутых зонах Universal SSL авторитетный DNS Cloudflare может на момент запроса отдать автоматически управляемый CAA RRset, который перекрывает CAA-записи владельца домена.

Риск

Опасность не в том, что Cloudflare взломали. Опасность тише: защитный механизм может существовать в ожидаемой политике клиента, но не сохраниться в CAA RRset, который оценивает центр сертификации.

Это может убрать привязку к аккаунту и методу проверки, которая должна снижать риск несанкционированного выпуска сертификата при сетевых атаках на проверку контроля домена.

Прецедент

Инцидент jabber.ru 2023 года остаётся правильной тревожной историей не потому, что он доказывает эксплуатацию против клиентов Cloudflare, а потому, что показывает класс атаки: если можно повлиять на трафик проверки контроля домена, выпуск сертификата становится полем боя.

Предотвращение

Для клиентов, которым действительно нужно строгое применение RFC 8657, практический предотвращающий путь — уйти из затронутого пути автоматического управления CAA в Universal SSL, но только после того, как уже активен другой действующий Cloudflare edge certificate.

Мониторинг CT полезен как видимость после выпуска. Это не предотвращение, не автоматическая классификация инцидента и не способ закрыть короткое окно для MITM-атаки.

Аудио-обзор

Download audio file

Аудио-обзор того, как Cloudflare Universal SSL ослабляет защиту по RFC 8657.

Аудиопрезентация: Атака на jabber.ru (2023) вскрывает критическую уязвимость Cloudflare в 2026 году. Пока на английском языке.. Автор:David Osipov. Лицензия: CC BY 4.0.

Видео-обзор

Видео-обзор разрыва в валидации CAA в Cloudflare и уязвимости для MitM-атак.

Брешь в защите Cloudflare: Как атака на jabber.ru в 2023 году вскрывает критическую уязвимость в 2026. Автор:David Osipov. Лицензия: CC BY 4.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во-первых, есть базовый стандарт CAA [13], обновляющий оригинальный [14]. Это можно назвать “доверием на уровне бренда”. Он позволяет добавить в 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)

Здесь в игру вступает [15]. Опубликованный в , он был разработан специально для предотвращения подобных атак. Это апгрейд от “доверия на уровне бренда” к “доверию на уровне процесса”. Он добавляет два критических параметра: 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[16].

Параметр 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 и др.) [17a]. Эти записи не используют параметры accounturi или validationmethods.

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

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

  1. ... IN CAA 0 issue "letsencrypt.org; accounturi=.../MY_ACCOUNT_ID" (Ваша защищенная запись заменяется на…)
  2. ... 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 с хостингом. Эта магия должна переопределять вашу безопасность, чтобы функционировать.

Сравнение поведения провайдеров
Тип провайдераПровайдерКонфликт “Продукт” vs “Безопасность”
Интегрированная платформаCloudflareКритический сбой. Внедряет разрешающие записи, которые активно перезаписывают пользовательские accounturi. [18a]
Интегрированная платформаVercelСхожее поведение; абстрагирует детали выпуска, часто конфликтуя со строгими политиками. [19]
Интегрированная платформаNetlifyКонфликт устранен. В отличие от Cloudflare, Netlify официально публикует свой ACME accounturi, позволяя пользователям защитить домен. [20a] [21]
Облачный провайдерAWS (ACM)Стандартное поведение. Требует issue "amazon.com" (только при наличии CAA), не вмешивается в записи других CA и не перезаписывает ограничения пользователя. [22]
Облачный провайдерGoogle CloudСтандартное поведение. Требует issue "pki.goog" (только при наличии CAA) и уважает пользовательские ограничения. [23]
Чистый DNS-провайдерAWS (Route 53)Нет конфликта. Полностью поддерживает кастомные CAA записи без вмешательства. [24]

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

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

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

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

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

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

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

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

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

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

Результаты голосования по SC067v3 (Июль 2024)
КатегорияГолосаУровень одобренияКлючевые участники
Эмитенты (CAs)22100% (22 За, 0 Против)Let’s Encrypt, DigiCert, Sectigo, GlobalSign
Потребители4100% (4 За, 0 Против)Google, Apple, Mozilla, Opera

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

Согласно текущему поэтапному внедрению Baseline Requirements:

  • : минимум 2 удалённые Network Perspectives, с кворумом.
  • : минимум 3 удалённые Network Perspectives.
  • : минимум 4 удалённые Network Perspectives.
  • : минимум 5 удалённых Network Perspectives.

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

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

MPIC vs RFC 8657 — Сравнение
КонтрольОсновная цельУстраняемые угрозы
MPIC (Многоперспективное подтверждение выдачи)Требовать подтвержденную валидацию с нескольких независимых сетевых точек наблюдения перед выдачей.Перехват на сетевом уровне / BGP-перехват; предотвращает выдачу на основе единственной скомпрометированной точки наблюдения.
RFC 8657 (Привязка аккаунта)Привязать выдачу к конкретному ACME-аккаунту и ограничить разрешенные методы валидации.Недобросовестные администраторы, скомпрометированные субаккаунты и злоупотребления делегированными/сторонними DNS-операторами.

Кратко: MPIC существенно снижает риск, но это не панацея. Исследование Princeton/USENIX 2023 года [27] показало 88% медианной устойчивости для оцененного multi-vantage-развёртывания Let’s Encrypt против 76% у проверки из одной точки, а работа Princeton/IMC 2025 года [28] показала, что оптимальные MPIC-развёртывания предотвращали ошибочную выдачу сертификата более чем в 87% оцененных реальных BGP-перехватов. Точная остаточная поверхность риска зависит от DNS, RPKI, расположения точек проверки, правил кворума и реального поведения маршрутизации [29].

Именно поэтому защита на уровне идентификации вроде привязки аккаунта RFC 8657 остаётся обязательной для высокоценных доменов. MPIC должен отсеивать самые простые локальные сетевые атаки, но он не заменяет accounturi и validationmethods.

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

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

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

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

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

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

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

Поддержка RFC 8657 (привязка аккаунта) в индустрии
ОрганизацияРольСтатусДетали и доказательства
Let’s EncryptCAПолная поддержкаПолностью реализовано в production с января 2023. Строгие требования синтаксиса для accounturi. [31] [32] [33]
Google Trust ServicesCAПолная поддержкаПоддерживается в соответствии с GTS CPS v5.22 (раздел 4.2.4) [34]; Обязательна в Chrome Root Program Policy v1.7 для автоматизированных решений [35].
DigiCertCAТолько для нового поколенияПринято как обязательная зависимость для метода валидации «DNS-PERSIST» в черновиках ноября 2025. [36]
Amazon Trust ServicesCAЧерновик/БетаСоавтор черновика постоянной DNS; предлагает стандартизировать привязку для «Canonical Authorization Domain Names». [30b]
FastlyCDN / MSPЧерновик/БетаСоавтор черновика постоянной DNS, сигнализирует архитектурный переход к привязке аккаунта. [30c]
NetlifyХостингПоддерживаетсяДоказательство реализуемости. С Netlify публикует свой accounturi в документации, доказывая, что поддержка на уровне платформы возможна. [20b]
CloudflareCDN / MSPНарушеноUniversal SSL внедряет разрешающие записи, которые переопределяют пользовательские ограничения. Пользователи должны платить за «Custom Certificates» для обхода. [18b]

Синергия с DNSSEC

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

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

— Birge-Lee et al., «Cryptographically-Secured Domain Validation» (2024) [38]

Без accounturi, даже подписанный DNSSEC домен уязвим, если злоумышленник может перехватить трафик валидации (как видно из инцидента в Венесуэле). Поддерживая RFC 8657, владелец домена может криптографически заблокировать выдачу на конкретный ключ аккаунта. Переопределение этих записей Cloudflare фактически понижает безопасность домена, независимо от того, использует ли он DNSSEC или нет.

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

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

  • — Взлом DigiNotar: Полная компрометация CA привела к выдаче мошеннических сертификатов для Google, Yahoo и других, использовавшихся для MitM-атак на государственном уровне. [39] [40a] accounturi (или даже базовый CAA) был бы защитой.
  • - — WoSign и StartCom: Этим CA отказали в доверии из-за многочисленных сбоев, включая выдачу сертификатов без надлежащей валидации. [41] [40b] validationmethods предотвратил бы выдачу через нестандартные, более слабые методы.
  • — Цепочка веб-уязвимостей: Исследователь показал, как простая уязвимость path traversal на веб-сервере может быть использована для прохождения проверки http-01. [42] Политика validationmethods=dns-01 сделала бы этот целый класс атак бесполезным.
  • — Исследование BGP-перехвата (Принстон): Фундаментальная статья Принстонского университета [25b] продемонстрировала, как BGP-перехват может быть использован для обхода валидации http-01. Атака на jabber.ru была реальной реализацией этой точной модели угрозы (перехват на сетевом уровне).
  • Январь 2026 — утечки маршрутов в Венесуэле: Массовая утечка маршрутов, затронувшая CANTV (AS8048), показала, что проблемы с BGP остаются постоянной угрозой современного интернета. Хотя Cloudflare в данном случае связывает событие с ошибкой конфигурации, а не злонамеренным действием, это доказывает, что перехват трафика — обычное явление, делающее строгую привязку к аккаунту (защита, которую обеспечивает RFC 8657) обязательной, а не опциональной. [9b]

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

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

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

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

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

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

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

Акт 4 ():

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

Акт 5 ():

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

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

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

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

Главное противоречие: продуктово-безопасностный компромисс, а не доказанный мотив

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

Это противоречит публичной записи. RFC 8657 был опубликован в , а Cloudflare имеет долгую историю внедрения протоколов безопасности, таких как TLS 1.3 [44] и QUIC [45], ещё до финализации стандарта.

Эта история не доказывает мотив, но она ослабляет объяснение “мы должны ждать”. Более узкий и безопасный вывод такой: публичное поведение выглядит как продуктово-безопасностный компромисс, а не как документированная техническая невозможность.

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

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

  1. Стандарт уже “принят”: RFC 8657 уже является Предложенным Стандартом (Proposed Standard) на треке стандартизации IETF.
  2. Статус “черновика” не оправдание: У Cloudflare есть долгая история внедрения протоколов за годы до их финализации.
    • TLS 1.3: Cloudflare анонсировала поддержку , за до финализации RFC. [46]
    • QUIC: Cloudflare поддержала его , почти за до публикации RFC. [47a]
    • ECH: Они поддерживают его с , несмотря на то, что он до сих пор в статусе черновика. [48] [49]

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

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

Ключевой момент не в мотиве. Ключевой момент в том, что публичный путь предотвращения для многих пользователей Free/Pro оказывается платным, требует миграции или связан с операционным риском.

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

Значит, спор не только о стандартах. Он о том, должен ли продукт сохранять пользовательские CAA-ограничения сквозно по умолчанию или требовать перехода на другой путь сертификатов, платную надстройку либо другого провайдера.

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

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

Горизонтальная гистограмма Statista под названием 'Cloudflare обеспечивает защиту для каждого пятого веб-сайта', иллюстрирующая долю веб-сайтов в мире, использующих указанные сервисы обратного прокси по состоянию на 19 ноября 2025 года. Данные показывают, что Cloudflare является доминирующим провайдером: его используют 20,4% веб-сайтов. Другие провайдеры имеют значительно меньшие доли: Amazon CloudFront — 1,6%, Fastly — 0,9%, Akamai — 0,8% и DDoS-Guard — 0,7%.

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

  1. Сделать Universal SSL безопасным по умолчанию: Прекратить внедрение разрешающих записей. Вместо этого внедрять ограничивающие записи с использованием accounturi для собственных внутренних ACME-аккаунтов Cloudflare. Это даст пользователям лучшее из двух миров: они защищены по умолчанию, и если они добавят свою запись accounturi, обе будут валидными (их и Cloudflare), но не запись злоумышленника.
  2. Обеспечить полный контроль пользователя: Обновить логику DNS. Если пользователь определяет запись для letsencrypt.org, не внедрять дублирующую разрешающую запись для того же CA. Доверяйте своему пользователю. Это простое if (user_record_exists) { do_not_inject }
  3. Быть прозрачными: Обновить документацию [17b], чтобы явно объяснять это поведение переопределения и создаваемые им риски, вместо того чтобы прятать это в мелком шрифте.

Вопросы, на которые Cloudflare всё ещё должна ответить

  1. Когда клиент Universal SSL публикует accounturi или validationmethods, сохраняются ли эти параметры в CAA RRset, который реально видят центры сертификации?
  2. Если нет, почему продукт позволяет клиентам думать, что они используют более строгий контроль выпуска сертификатов, пока Universal SSL может отдавать более широкую политику?
  3. Есть ли бесплатный путь для клиентов Free и Pro, который сохраняет строгое применение RFC 8657 и при этом оставляет HTTPS на edge Cloudflare?
  4. Разделяет ли Cloudflare в клиентской документации предотвращающую mitigation и post-issuance обнаружение через CT?
  5. По каким сигналам клиенты должны отличать нормальный выпуск Universal SSL, backup certificates и shared certificates от подозрительного выпуска в CT-логах?

Certificate Transparency — это не ремень безопасности

CT полезен. Но его очень легко переоценить.

Запись в CT-логе доказывает, что сертификат существует. Сама по себе она не доказывает, что сертификат злонамеренный, безобидный, ожидаемый, неожиданный, управляется Cloudflare, управляется третьей стороной, является backup certificate, renewal или shared certificate, в который домен попал вместе с другими именами.

Здесь это различие особенно важно, потому что Universal SSL сам является автоматизированной системой выпуска сертификатов. В такой среде новая запись в CT — не автоматическая пожарная тревога. Иногда это дым. Иногда это тостер. Иногда это действительно горящее здание.

Владельцу домена всё равно нужны мониторинг, triage, полномочия отозвать или заменить сертификат и процесс, который отличает ожидаемый выпуск Cloudflare от неожиданного пути выпуска [5c] [6c].

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

Пока Cloudflare не изменит путь Universal SSL так, чтобы CA реально видел пользовательские ограничения accounturi и validationmethods в фактически отдаваемом CAA RRset, у клиентов Free и Pro нет документированного бесшовного preventive-пути при сохранении HTTPS через тот же Cloudflare edge path.

Реалистичные варианты такие:

  1. Заплатить за подходящий путь сертификатов Cloudflare, например Advanced Certificate Manager / Advanced Certificates.
  2. Обновить тариф или мигрировать на схему, которая поддерживает нужный контроль над сертификатами.
  3. Уйти из затронутого пути Universal SSL.
  4. Перейти к провайдеру DNS/CDN/сертификатов, который сохраняет RFC 8657 accounturi / validationmethods в фактически отдаваемом CAA RRset без отдельного платного шлюза.
  5. Принять остаточный риск и использовать мониторинг Certificate Transparency только как средство обнаружения.

Если вы отключаете Universal SSL, делайте это только после того, как уже активен другой действующий Cloudflare edge certificate. Иначе новые TLS-соединения сломаются. Мониторинг CT помогает найти ошибочно выпущенный сертификат уже после выпуска; он не предотвращает сам выпуск.

Поддержать мою работу

Если этот материал сэкономил ваше время или вдохновил на новые идеи, поддержите мою работу.

Кофейчик на Ko-fi

Самый быстрый способ выразить благодарность

Для анонимных пожертвований вы можете поддержать меня с помощью криптовалюты. Нажмите на любой адрес, чтобы скопировать.

Bitcoin (BTC)

Сеть: Bitcoin

bc1q99evmn80nmfk8vyxs2emc9t4a4k2pdmkjlwah4
Ethereum (ETH)

Сеть: Ethereum

0x81bF6f880D0010F47830cbF01c0F3C8a6E825Cc3
BNB (Binance Coin)

Сеть: BNB Smart Chain (BSC)

0x81bF6f880D0010F47830cbF01c0F3C8a6E825Cc3
USDT (Tether)

Сеть: TRON

TWnLLRVX9NgZAwD5LhrzvnEfg69jxEAGgA
Monero (XMR)

Сеть: Monero

88MbtU2R1ufG2BcnCrkqmn3oYxvvKKR1u2yb6YeZZrQV8akocEnrHrrhzoGowkijRpLsAzTjGczfEPdL9wyzrotLTSXbEg6
Solana (SOL)

Сеть: Solana

BBTdnfdojXzifJaV4CG8LcsNiZpfvva5o9cCpbS3Esmg
Bitcoin Cash (BCH)

Сеть: Bitcoin Cash

bitcoincash:qqhv3qtsldf0w8cjzzqyame35urs0cf2xg92s2chf0
Litecoin (LTC)

Сеть: Litecoin

ltc1qy6wkwtlmzt0kngx8wrgt6x5v5nn2s7wqyvh23m
TRX (TRON)

Сеть: TRON

TWnLLRVX9NgZAwD5LhrzvnEfg69jxEAGgA
История версий документа содержит 8 версий. Нажмите на любую строку, чтобы просмотреть подробные изменения для этой версии.

История версий8

ВерсияСтатусДатаДействия

Источники

52 источников

Источники

52 источников
Portrait of David Osipov

Давид Осипов

Инновационный продуктовый лидер с в B2B SaaS, специализирующийся на решениях на базе ИИ, корпоративных IT-продуктах на основе данных и безопасных SaaS-платформах. Выпускник ВШМ СПбГУ. Активный картограф OpenStreetMap в Грузии и гражданский ученый. Wikidata: Q130604188, ISNI: 0000 0005 1802 960X.

David OsipovDavidZurabovichOsipovMScB2B Product Manager