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

David Osipov

doi:10.5281/zenodo.18330221

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

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

Давид Осипов

• 31 декабря 2025 г. • 20 мин чтения • Updated: 21 янв. 2026 г.

Автор: David Osipov

Опубликовано: 2025-12-31

Изменено: 2026-01-21

Время чтения: 20 мин чтения

Лицензия: CC BY 4.0

Версия: 1.7

Информация о статье

Раздел:: Кибербезопасность
Уровень:: Брифинг
Версия:: 1.7
Опубликовано:: 31 декабря 2025 г.
Изменено:: 21 января 2026 г.
Время чтения:: 20 мин чтения
Слов:: 4 327
Рекомендуемое:: Да
Язык:: RU

Информация об авторе

Автор:: David Osipov
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

Цифровой идентификатор объекта (DOI): 10.5281/zenodo.18330221
Концептуальный DOI (Все версии) :
10.5281/zenodo.18201411 Этот DOI представляет собой постоянную ссылку на все версии данного документа (Concept DOI).
Идентификаторы безопасности:: NotCVE NotCVE-2026-0001
Лицензия:: CC BY 4.0

Ключевые слова

dns
caa
rfc-8657
cloudflare
mitm
анализ-безопасности
lets-encrypt
продвинутый-пользователь
архив
bgp-хайджекинг
rfc-8659
valdikss
jabber.ru
http-01
dns-01

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

Стиль APA
Osipov, D. (2025) Атака на jabber.ru вскрывает критическую уязвимость Cloudflare в 2026 году. Доступно по адресу https://doi.org/10.5281/zenodo.18330221.
BibLaTeX
@article{osipov-2025-jabber-ru-cloudflare-20262025-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 = {Атака на jabber.ru вскрывает критическую уязвимость Cloudflare в 2026 году}, date = {2025-12-31}, doi = {10.5281/zenodo.18330221}, url = {https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/} }

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

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

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

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

Автор:: David Osipov
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) Атака на jabber.ru вскрывает критическую уязвимость Cloudflare в 2026 году. Доступно по адресу https://doi.org/10.5281/zenodo.18330221.

BibLaTeX

              @article{osipov-2025-jabber-ru-cloudflare-20262025-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 = {Атака на jabber.ru вскрывает критическую уязвимость Cloudflare в 2026 году},
  date = {2025-12-31},
  doi = {10.5281/zenodo.18330221},
  url = {https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/}
}

Аннотация

В этой статье анализируется NotCVE-2026-0001, критическая уязвимость в Cloudflare Universal SSL, где автоматическое внедрение разрешающих CAA-записей активно аннулирует стандарт IETF RFC 8657. Перезаписывая определенные пользователем параметры привязки аккаунта, эта конфигурация вновь открывает ту самую брешь в безопасности, которая эксплуатировалась в MitM-атаке на jabber.ru в 2023 году, оставляя миллионы доменов уязвимыми для BGP-перехвата и несанкционированного выпуска TLS-сертификатов. Анализ показывает, что это не технический недосмотр, а осознанное архитектурное решение, нейтрализующее защитные механизмы `accounturi` и `validationmethods`. Cloudflare должна внедрить строгую привязку аккаунтов ACME для устранения этого риска.

Предыстория

Это расследование началось после моей собственной неудачной попытки внедрить CAA-записи по стандарту RFC 8657 на доменах, размещенных на Cloudflare. Обнаружив, что Cloudflare молча *перезаписывает* мои усиленные настройки безопасности, я понял, что миллионы пользователей бесплатного тарифа неосознанно уязвимы для той же атаки, которая скомпрометировала jabber.ru в 2023 году. После месяца молчания со стороны комьюнити-команды Cloudflare и последовавшего снисходительного ответа со ссылкой на «стандартные сроки внедрения», я понял, что проблеме нужна более широкая огласка. Моя последующая статья на Хабре стала лучшим постом недели, подтвердив обеспокоенность сообщества этой искусственной брешью в защите.

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

По состоянию на 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-спуфинг (альтернативный вектор манипуляции сетевым уровнем).

Аудио-обзор

Аудиопрезентация: Атака на jabber.ru (2023) вскрывает критическую уязвимость Cloudflare в 2026 году. Пока на английском языке. by David Osipov is licensed under CC BY 4.0 .
Аудио-обзор того, как Cloudflare Universal SSL ослабляет защиту по RFC 8657.

Видео-обзор

Брешь в защите Cloudflare: Как атака на jabber.ru в 2023 году вскрывает критическую уязвимость в 2026 by David Osipov is licensed under CC BY 4.0 .
Видео-обзор разрыва в валидации CAA в Cloudflare и уязвимости для MitM-атак.

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 происходят постоянно, и они всегда были частью интернета. ^[3a]

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

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

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

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

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

Проблему лучше всего понять через призму 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 и др.) ^[11a]. Эти записи не используют параметры 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 с хостингом. Эта магия должна переопределять вашу безопасность, чтобы функционировать.

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

Это показывает четкое, отраслевое разделение. “Чистые 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 ^[19a] как на основную мотивацию — модель атаки, описанная там, является именно той угрозой, для смягчения которой разработан MPIC.^[20]

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

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

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

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

15 сентября 2024: MPIC становится РЕКОМЕНДОВАННЫМ для всех CA.
15 марта 2025: MPIC становится ОБЯЗАТЕЛЬНЫМ (требуется минимум 2 независимые перспективы).
15 марта 2026: Требование ужесточается до минимума 3 независимых перспектив.

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

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

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

Кратко: 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 ^[22a]. Этот новый черновой стандарт позволяет использовать «Постоянную валидацию 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 Encrypt	CA	Полная поддержка	Полностью реализовано в production с января 2023. Строгие требования синтаксиса для `accounturi`. ^[23] ^[24] ^[25]
Google Trust Services	CA	Полная поддержка	Поддерживается в соответствии с GTS CPS v5.22 (раздел 4.2.4) ^[26]; Обязательна в Chrome Root Program Policy v1.7 для автоматизированных решений ^[27].
DigiCert	CA	Только для нового поколения	Принято как обязательная зависимость для метода валидации «DNS-PERSIST» в черновиках ноября 2025. ^[28]
Amazon Trust Services	CA	Черновик/Бета	Соавтор черновика постоянной DNS; предлагает стандартизировать привязку для «Canonical Authorization Domain Names». ^[22b]
Fastly	CDN / MSP	Черновик/Бета	Соавтор черновика постоянной DNS, сигнализирует архитектурный переход к привязке аккаунта. ^[22c]
Netlify	Хостинг	Поддерживается	Доказательство реализуемости. С конца 2023 года Netlify публикует свой `accounturi` в документации, доказывая, что поддержка на уровне платформы возможна. ^[14b]
Cloudflare	CDN / MSP	Нарушено	Universal SSL внедряет разрешающие записи, которые переопределяют пользовательские ограничения. Пользователи должны платить за «Custom Certificates» для обхода. ^[12b]

Синергия с 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] ^[32a] accounturi (или даже базовый CAA) был бы защитой.
2015-2016 — WoSign и StartCom: Этим CA отказали в доверии из-за многочисленных сбоев, включая выдачу сертификатов без надлежащей валидации. ^[33] ^[32b] validationmethods предотвратил бы выдачу через нестандартные, более слабые методы.
31 августа 2017 — Цепочка веб-уязвимостей: Исследователь показал, как простая уязвимость path traversal на веб-сервере может быть использована для прохождения проверки http-01. ^[34] Политика validationmethods=dns-01 сделала бы этот целый класс атак бесполезным.
Август 2018 — Исследование BGP-перехвата (Принстон): Фундаментальная статья Принстонского университета ^[19b] продемонстрировала, как BGP-перехват может быть использован для обхода валидации http-01. Атака на jabber.ru была реальной реализацией этой точной модели угрозы (перехват на сетевом уровне).
Январь 2026 — утечки маршрутов в Венесуэле: Массовая утечка маршрутов, затронувшая CANTV (AS8048), показала, что проблемы с BGP остаются постоянной угрозой современного интернета. Хотя Cloudflare в данном случае связывает событие с ошибкой конфигурации, а не злонамеренным действием, это доказывает, что перехват трафика — обычное явление, делающее строгую привязку к аккаунту (защита, которую обеспечивает RFC 8657) обязательной, а не опциональной. ^[3b]

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

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

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

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

Акт 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 происходят постоянно, ^[3c] в контексте инцидента в Венесуэле, я открыл новое, конкретное обсуждение на их форуме комьюнити, в котором спрашиваю, почему их SSL-продукт отключает основную защиту от этих самых утечек. Вы можете поддержать этот запрос здесь: ^[4b].

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

Член команды 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. ^[39a]
- ECH: Они поддерживают его с 8 декабря 2020 года, несмотря на то, что он до сих пор в статусе черновика. ^[40] ^[41]

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

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

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

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

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

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

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

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

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

Пока 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 закрыть эту брешь для всех, а не только для платящих клиентов.

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

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

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

Кофейчик на 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

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

	Версия	Дата	Действия
	v1.7	21.01.2026	Просмотр архива
Изменения: Интегрирована независимая валидация: NotCVE-2026-0001 (CVSS 8.7) и кейс CERT/CC VINCE VU#840183. Добавлен раздел 'Статус уязвимости' с техническими классификациями (CWE/CAPEC). Контекстуализирован патч Cloudflare от 19 января для ACME WAF bypass как независимое исправление, не связанное с проблемой CAA. Улучшено семантическими HTML-тегами для дат и элементов данных.
	v1.6	17.01.2026	Просмотр архива
Изменения: Добавлен анализ draft-ietf-acme-dns-persist-00 и матрица поддержки RFC 8657 по отраслям. Интегрирована дискуссия Генри Бирже-Ли о синергии DNSSEC из CA/B Forum. Уточнены механизмы привязки аккаунтов для многоклиентских платформ. Обновлены некоторые данные по состоянию на январь 2026 года.
	v1.2	15.01.2026	Просмотр архива
Изменения: Добавлены отсутствующие разделы: Audio/Video Overview, историческая справка по взломам PKI, анализ MPIC и SC067v3, таблица сравнения провайдеров, детальный анализ попыток контакта с Cloudflare, историческая справка по внедрению черновиков протоколов и инструкции по защите.
	v1.1	15.01.2026
Изменения: Добавлен анализ утечки BGP в Венесуэле (январь 2026) как подтверждение вектора атаки. Связана новая обсуждение в комьюнити Cloudflare о требованиях поддержки RFC 8657.
	v1.0	30.12.2025	Просмотр архива
Изменения: Первичная публикация.

Источники

44 источников

website
NotCVE.org (2026) . NotCVE-2026-0001 — Cloudflare Universal SSL CAA Augmentation .
↩
View Source

Retrieved 2026-01-21
Archived snapshots: Internet Archive on 2026-01-21
article
Hrushikesh Deshpande, Andrew Mitchell, Leland Garofalo (2026) . How we mitigated a vulnerability in Cloudflare's ACME validation logic .
↩
View Source

Retrieved 2026-01-21
Archived snapshots: Internet Archive on 2026-01-19
article
Bryton Herdes (2026) . A closer look at a BGP anomaly in Venezuela .
↩ ^a ↩ ^b ↩ ^c
View Source

Retrieved 2026-01-15
Archived snapshots: Internet Archive on 2026-01-13
website
Cloudflare Community (2026) . Universal SSL exposes domains to BGP leaks (re: Venezuela analysis) .
↩ ^a ↩ ^b
View Source

Retrieved 2026-01-15
Archived snapshots: archive.today on 2026-01-15
website
Cloudflare Community (2025) . Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-29
Archived snapshots: archive.today on 2025-11-29
article
ValdikSS (2023) . Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service .
↩
View Source

Retrieved 2025-11-29
Archived snapshots: Internet Archive on 2025-10-01
rfc
DOI: 10.17487/RFC8659
Phillip Hallam-Baker, Rob Stradling, Jacob Hoffman-Andrews (2019) . DNS Certification Authority Authorization (CAA) Resource Record .
↩
rfc
DOI: 10.17487/RFC6844
Phillip Hallam-Baker, Rob Stradling (2013) . DNS Certification Authority Authorization (CAA) Resource Record .
↩
rfc
DOI: 10.17487/RFC8657
Hugo Landau (2019) . Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding .
↩
website
Landau, H. (2023) . XMPP CA/jabber.ru incident .
↩
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-09-03
documentation
Cloudflare . Add CAA records - Cloudflare SSL/TLS docs .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-11-29
website
Cloudflare Community (2025) . Cloudflare nameservers ignore CAA record validationmethods and accounturi .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-08
Archived snapshots: archive.today on 2025-11-30
documentation
Vercel . Working with DNS .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-06-12
documentation
Netlify (2023) . HTTPS (SSL) | Netlify Docs .
↩ ^a ↩ ^b
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
website
Netlify Support Forums (2023) . Let's Encrypt accounturi for CAA record .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2025-07-10
documentation
AWS . Set up to use AWS Certificate Manager .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-07-29
documentation
Google Cloud . Use Google-managed SSL certificates .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
website
AWS (2017) . Amazon Route 53 now supports CAA records .
↩
View Source

Retrieved 2025-11-08
conference
Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J., Mittal, P. (2018) . Bamboozling Certificate Authorities with BGP .
↩ ^a ↩ ^b
ISBN: 978-1-939133-04-5

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-10-01
report
CA/Browser Forum (2024) . Ballot SC067v3: Require domain validation and CAA checks to be performed from multiple Network Perspectives .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-10-12
paper
DOI: 10.48550/arXiv.2302.08000
Cimaszewski, G., Birge-Lee, H., Wang, L., Rexford, J., Mittal, P. (2023) . How Effective is Multiple-Vantage-Point Domain Control Validation? .
↩
report
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) .
↩ ^a ↩ ^b ↩ ^c
View Source

Archived snapshots: Internet Archive on 2026-01-17
documentation
Let's Encrypt Community Support (2023) . Issue certificates only to specific agent keys .
↩
View Source

Archived snapshots: Internet Archive on 2026-01-17
website
Let's Encrypt Community Support (2022) . PROD Support for RFC8657 CAA constraints .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
website
University of North Carolina at Charlotte (2024) . Let's Encrypt using accounturi .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2025-01-14
documentation
Google Trust Services LLC (2025) . Google Trust Services, Certification Practice Statement v.5.22 .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
documentation
Google Chrome (2025) . Chrome Root Program Policy, Version 1.7 .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-06
article
DigiCert (2025) . A New DNS Validation Method for Simplified Certificate Automation .
↩
View Source

Archived snapshots: Internet Archive on 2026-01-17
website
Birge-Lee, H. (2025) . The Use of DNSSEC by Certificate Authorities .
↩
View Source

Archived snapshots: Internet Archive on 2026-01-17
paper
Birge-Lee, H., Cimaszewski, G. H., Krahenbuhl, C., и др. (2024) . Cryptographically-Secured Domain Validation .
View all 6 authors
Birge-Lee, H., Cimaszewski, G. H., Krahenbuhl, C., Wang, L., Gable, A., Mittal, P.
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2025-04-16
website
Wikipedia . DigiNotar - Wikipedia .
↩
View Source

Retrieved 2025-11-08
website
SSLMate . Timeline of Certificate Authority Failures .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-09-17
article
Kathleen Wilson (2016) . Distrusting New WoSign and StartCom Certificates .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-09-21
article
Gualtieri, M. (2017) . Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt .
↩
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-09-07
article
Осипов, Давид (2025) . Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023 .
↩
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-08-12
rfc
DOI: 10.17487/RFC8446
Eric Rescorla (2018) . The Transport Layer Security (TLS) Protocol Version 1.3 .
↩
rfc
DOI: 10.17487/RFC9000
Jana Iyengar, Martin Thomson (2021) . QUIC: A UDP-Based Multiplexed and Secure Transport .
↩
article
Nick Sullivan (2016) . Introducing TLS 1.3 .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-08-23
article
Nick Jones (2018) . Get a head start with QUIC .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-06-20
report
Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher A. Wood (2025) . TLS Encrypted Client Hello . Internet Engineering Task Force.
↩
View Source
article
Christopher Patton (2020) . Good-bye ESNI, hello ECH! .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-09-05
website
W3Techs (2026) . Cloudflare — W3Techs Reverse Proxy Services Usage Statistics .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: archive.today on 2026-01-17
website
Tristan Gaudiaut (2025) . Cloudflare, a hidden pillar of the internet .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-11-30
website
W3Techs.com (2025) . Usage of Reverse Proxy Services for Websites, November 2025 .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: archive.today on 2025-11-30

Источники

44 источников

website
NotCVE.org (2026) . NotCVE-2026-0001 — Cloudflare Universal SSL CAA Augmentation .
↩
View Source

Retrieved 2026-01-21
Archived snapshots: Internet Archive on 2026-01-21
article
Hrushikesh Deshpande, Andrew Mitchell, Leland Garofalo (2026) . How we mitigated a vulnerability in Cloudflare's ACME validation logic .
↩
View Source

Retrieved 2026-01-21
Archived snapshots: Internet Archive on 2026-01-19
article
Bryton Herdes (2026) . A closer look at a BGP anomaly in Venezuela .
↩ ^a ↩ ^b ↩ ^c
View Source

Retrieved 2026-01-15
Archived snapshots: Internet Archive on 2026-01-13
website
Cloudflare Community (2026) . Universal SSL exposes domains to BGP leaks (re: Venezuela analysis) .
↩ ^a ↩ ^b
View Source

Retrieved 2026-01-15
Archived snapshots: archive.today on 2026-01-15
website
Cloudflare Community (2025) . Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-29
Archived snapshots: archive.today on 2025-11-29
article
ValdikSS (2023) . Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service .
↩
View Source

Retrieved 2025-11-29
Archived snapshots: Internet Archive on 2025-10-01
rfc
DOI: 10.17487/RFC8659
Phillip Hallam-Baker, Rob Stradling, Jacob Hoffman-Andrews (2019) . DNS Certification Authority Authorization (CAA) Resource Record .
↩
rfc
DOI: 10.17487/RFC6844
Phillip Hallam-Baker, Rob Stradling (2013) . DNS Certification Authority Authorization (CAA) Resource Record .
↩
rfc
DOI: 10.17487/RFC8657
Hugo Landau (2019) . Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding .
↩
website
Landau, H. (2023) . XMPP CA/jabber.ru incident .
↩
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-09-03
documentation
Cloudflare . Add CAA records - Cloudflare SSL/TLS docs .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-11-29
website
Cloudflare Community (2025) . Cloudflare nameservers ignore CAA record validationmethods and accounturi .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-08
Archived snapshots: archive.today on 2025-11-30
documentation
Vercel . Working with DNS .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-06-12
documentation
Netlify (2023) . HTTPS (SSL) | Netlify Docs .
↩ ^a ↩ ^b
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
website
Netlify Support Forums (2023) . Let's Encrypt accounturi for CAA record .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2025-07-10
documentation
AWS . Set up to use AWS Certificate Manager .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-07-29
documentation
Google Cloud . Use Google-managed SSL certificates .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
website
AWS (2017) . Amazon Route 53 now supports CAA records .
↩
View Source

Retrieved 2025-11-08
conference
Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J., Mittal, P. (2018) . Bamboozling Certificate Authorities with BGP .
↩ ^a ↩ ^b
ISBN: 978-1-939133-04-5

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-10-01
report
CA/Browser Forum (2024) . Ballot SC067v3: Require domain validation and CAA checks to be performed from multiple Network Perspectives .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-10-12
paper
DOI: 10.48550/arXiv.2302.08000
Cimaszewski, G., Birge-Lee, H., Wang, L., Rexford, J., Mittal, P. (2023) . How Effective is Multiple-Vantage-Point Domain Control Validation? .
↩
report
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) .
↩ ^a ↩ ^b ↩ ^c
View Source

Archived snapshots: Internet Archive on 2026-01-17
documentation
Let's Encrypt Community Support (2023) . Issue certificates only to specific agent keys .
↩
View Source

Archived snapshots: Internet Archive on 2026-01-17
website
Let's Encrypt Community Support (2022) . PROD Support for RFC8657 CAA constraints .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
website
University of North Carolina at Charlotte (2024) . Let's Encrypt using accounturi .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2025-01-14
documentation
Google Trust Services LLC (2025) . Google Trust Services, Certification Practice Statement v.5.22 .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-17
documentation
Google Chrome (2025) . Chrome Root Program Policy, Version 1.7 .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2026-01-06
article
DigiCert (2025) . A New DNS Validation Method for Simplified Certificate Automation .
↩
View Source

Archived snapshots: Internet Archive on 2026-01-17
website
Birge-Lee, H. (2025) . The Use of DNSSEC by Certificate Authorities .
↩
View Source

Archived snapshots: Internet Archive on 2026-01-17
paper
Birge-Lee, H., Cimaszewski, G. H., Krahenbuhl, C., и др. (2024) . Cryptographically-Secured Domain Validation .
View all 6 authors
Birge-Lee, H., Cimaszewski, G. H., Krahenbuhl, C., Wang, L., Gable, A., Mittal, P.
↩
View Source

Retrieved 2026-01-17
Archived snapshots: Internet Archive on 2025-04-16
website
Wikipedia . DigiNotar - Wikipedia .
↩
View Source

Retrieved 2025-11-08
website
SSLMate . Timeline of Certificate Authority Failures .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-09-17
article
Kathleen Wilson (2016) . Distrusting New WoSign and StartCom Certificates .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-09-21
article
Gualtieri, M. (2017) . Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt .
↩
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-09-07
article
Осипов, Давид (2025) . Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023 .
↩
View Source

Retrieved 2025-11-08
Archived snapshots: Internet Archive on 2025-08-12
rfc
DOI: 10.17487/RFC8446
Eric Rescorla (2018) . The Transport Layer Security (TLS) Protocol Version 1.3 .
↩
rfc
DOI: 10.17487/RFC9000
Jana Iyengar, Martin Thomson (2021) . QUIC: A UDP-Based Multiplexed and Secure Transport .
↩
article
Nick Sullivan (2016) . Introducing TLS 1.3 .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-08-23
article
Nick Jones (2018) . Get a head start with QUIC .
↩ ^a ↩ ^b
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-06-20
report
Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher A. Wood (2025) . TLS Encrypted Client Hello . Internet Engineering Task Force.
↩
View Source
article
Christopher Patton (2020) . Good-bye ESNI, hello ECH! .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-09-05
website
W3Techs (2026) . Cloudflare — W3Techs Reverse Proxy Services Usage Statistics .
↩
View Source

Retrieved 2026-01-17
Archived snapshots: archive.today on 2026-01-17
website
Tristan Gaudiaut (2025) . Cloudflare, a hidden pillar of the internet .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: Internet Archive on 2025-11-30
website
W3Techs.com (2025) . Usage of Reverse Proxy Services for Websites, November 2025 .
↩
View Source

Retrieved 2025-11-30
Archived snapshots: archive.today on 2025-11-30

Давид Осипов

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

Blog Navigation Instructions

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

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

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

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

Стиль APA

BibLaTeX

Аннотация

Предыстория

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

Изменения:

Изменения:

Изменения:

Изменения:

Изменения:

Источники

Источники

Давид Осипов