TL;DR
Механизм
Cloudflare Universal SSL автоматически внедряет разрешающие CAA-записи, которые переопределяют пользовательские ограничения DNS, заставляя удостоверяющие центры игнорировать строгие проверки привязки к аккаунту.
Риск
Это открывает возможность для BGP-перехвата и сетевого вмешательства с целью получения несанкционированных TLS-сертификатов путем обхода параметров accounturi и validationmethods.
Прецедент
Эта конфигурация воссоздает брешь, эксплуатированную в MitM-атаке на jabber.ru в 2023 году, когда перехваченный трафик позволил пройти валидацию домена с помощью проверки http-01.
Решение
Cloudflare должна прекратить переопределять пользовательские DNS-записи или полностью внедрить RFC 8657, чтобы ограничить выдачу сертификатов только авторизованным ACME-аккаунтом владельца домена.
Введение: Критическая брешь в безопасности Cloudflare Universal SSL
Я обнаружил серьезную, но легко устранимую брешь в безопасности Cloudflare Universal SSL, затрагивающую миллионы пользователей. Мои попытки обсудить эту проблему напрямую с Cloudflare [1a] оказались… скажем так, безуспешными.
Проблему лучше всего понять через призму MitM-атаки на jabber.ru [2], произошедшей в . Тогда злоумышленники с государственной поддержкой смогли перехватить трафик jabber.ru на сетевом уровне. Это позволило им пройти валидацию домена с помощью проверки http-01 от Let’s Encrypt и получить валидный TLS-сертификат для домена. Им не потребовалось взламывать сам сервер.
RFC 8659 и RFC 8657: объяснение стандартов CAA
Чтобы понять проблему, нужно разобраться в решении. Защита от подобных атак строится на двух стандартах IETF.
1. Базовый стандарт: RFC 8659 (CAA)
Во-первых, есть базовый стандарт CAA [3], обновляющий оригинальный [4]. Это можно назвать “доверием на уровне бренда”. Он позволяет добавить в DNS запись:
david-osipov.vision. IN CAA 0 issue “letsencrypt.org”Эта запись сообщает всем Удостоверяющим Центрам (CA): “Только Let’s Encrypt может выпустить сертификат для моего домена.”
Это хорошо, но недостаточно. Это означает, что любой, кто сможет пройти проверку Let’s Encrypt, получит сертификат. Если злоумышленник перехватит ваш веб-сервер или (как в случае jabber.ru) ваш сетевой трафик, он пройдет проверку и получит валидный сертификат от вашего авторизованного CA.
2. Настоящий стандарт: RFC 8657 (Расширения ACME)
Здесь в игру вступает [5]. Опубликованный в , он был разработан специально для предотвращения подобных атак. Это апгрейд от “доверия на уровне бренда” к “доверию на уровне процесса”. Он добавляет два критических параметра: accounturi и validationmethods.
Параметр accounturi — это ваш “второй фактор”.
Запись говорит: “Только Let’s Encrypt, используя мой конкретный аккаунт, может выпустить сертификат для моего домена.”
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[6].
Параметр 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:
david-osipov.vision. IN CAA 0 issue “letsencrypt.org; validationmethods=dns-01”Если бы у jabber.ru была хотя бы одна из этих записей RFC 8657, атака была бы обречена с самого начала.
Проблема Cloudflare: Конфликт функциональности
Теперь к сути проблемы. Как B2B Product Manager, я не вижу здесь “баг” — я вижу конфликт функциональности, где потребности (плохо спроектированной) функции продукта активно разрушают безопасность пользователя.
В чем проблема: Когда вы используете бесплатный Universal SSL от Cloudflare, Cloudflare автоматически добавляет свои CAA-записи для партнерских CA (Let’s Encrypt, Google Trust Services и др.) [7a]. Эти записи не используют параметры 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. [8] |
| Интегрированная платформа | Vercel | Также внедряет разрешающие записи Let’s Encrypt. [9] |
| Интегрированная платформа | AWS (ACM) | Требует наличия разрешающей записи issue “amazon.com” для работы управляемых сертификатов. [10] |
| Интегрированная платформа | Google Cloud (Cert Manager) | Требует наличия записи issue “pki.goog”. Нет данных о поддержке RFC8657 [11] |
| Чистый DNS-хостинг | DNSimple | Нет конфликта. Как чистый DNS-провайдер, не вмешиваются в записи, но полная поддержка RFC8657 не подтверждена явно. [12] |
| Чистый DNS-хостинг | AWS (Route 53) | Нет конфликта. Полностью поддерживает кастомные CAA записи без вмешательства. [13] |
Это показывает четкое, отраслевое разделение. “Чистые DNS-провайдеры” продают вам безопасность и контроль. “Интегрированные платформы” продают удобство, часто за счет безопасности.
Ответ индустрии: Многоперспективное подтверждение выдачи (MPIC)
Пока многие платформы продолжали игнорировать или переопределять RFC 8657, CA/Browser Forum решил устранить основную причину на уровне валидации. В Форум одобрил Баллот SC-067 v3, требующий от Удостоверяющих Центров использовать многоперспективное подтверждение выдачи (MPIC) вместо проверки с единственной локальной точки наблюдения.
Связь с Принстоном
CA/Browser Forum специально ссылается на статью Принстонского университета 2018 года Bamboozling Certificate Authorities with BGP [14a] как на основную мотивацию — модель атаки, описанная там, является именно той угрозой, для смягчения которой разработан MPIC.[15]
Результаты голосования показывают необычно широкое согласие: изменение поддержали крупные эмитенты и крупные потребители платформ.
| Категория | Голоса | Уровень одобрения | Ключевые участники |
|---|---|---|---|
| Эмитенты (CAs) | 22 | 100% (22 За, 0 Против) | Let’s Encrypt, DigiCert, Sectigo, GlobalSign |
| Потребители | 4 | 100% (4 За, 0 Против) | Google, Apple, Mozilla, Opera |
График внедрения
Согласно обновленным Базовым Требованиям TLS и тексту баллота, развертывание было поэтапным:
- : MPIC становится РЕКОМЕНДОВАННЫМ для всех CA.
- : MPIC становится ОБЯЗАТЕЛЬНЫМ (требуется минимум 2 независимые перспективы).
- : Требование ужесточается до минимума 3 независимых перспектив.
Почему MPIC не заменяет RFC 8657
MPIC и RFC 8657 — это дополняющие друг друга меры контроля:
| Контроль | Основная цель | Устраняемые угрозы |
|---|---|---|
| MPIC (Многоперспективное подтверждение выдачи) | Требовать подтвержденную валидацию с нескольких независимых сетевых точек наблюдения перед выдачей. | Перехват на сетевом уровне / BGP-перехват; предотвращает выдачу на основе единственной скомпрометированной точки наблюдения. |
| RFC 8657 (Привязка аккаунта) | Привязать выдачу к конкретному ACME-аккаунту и ограничить разрешенные методы валидации. | Недобросовестные администраторы, скомпрометированные саб-аккаунты и злоупотребления делегированными/сторонними DNS-операторами. |
Кратко: MPIC значительно снижает риск массовых или оппортунистических атак на основе BGP, но не устраняет необходимость в блокировках на уровне аккаунта (защита, предоставляемая RFC 8657), когда задействованы мультитенантные или делегированные DNS-операторы.
Таким образом, отказ Cloudflare соблюдать accounturi и validationmethods остается значимой брешью в эшелонированной защите, даже несмотря на то, что MPIC должен устранить простейшие сетевые атаки к 2025 году.
Но… Это действительно проблема? (Да, это так)
Инцидент с jabber.ru — это основной, мощный кейс-стади, но веб-PKI — это кладбище похожих инцидентов, для предотвращения которых были созданы эти стандарты.
- — Взлом DigiNotar: Полная компрометация CA привела к выдаче мошеннических сертификатов для Google, Yahoo и других, использовавшихся для MitM-атак на государственном уровне. [16] [17a]
accounturi(или даже базовый CAA) был бы защитой. - - — WoSign и StartCom: Этим CA отказали в доверии из-за многочисленных сбоев, включая выдачу сертификатов без надлежащей валидации. [18] [17b]
validationmethodsпредотвратил бы выдачу через нестандартные, более слабые методы. - — Цепочка веб-уязвимостей: Исследователь показал, как простая уязвимость path traversal на веб-сервере может быть использована для прохождения проверки
http-01. [19] Политикаvalidationmethods=dns-01сделала бы этот целый класс атак бесполезным. - — Исследование BGP-перехвата (Принстон): Фундаментальная статья Принстонского университета [14b] продемонстрировала, как BGP-перехват может быть использован для обхода валидации
http-01. Атака наjabber.ruбыла реальной реализацией этой точной модели угрозы (перехват на сетевом уровне).
В каждом случае accounturi или validationmethods обеспечили бы критический, превентивный уровень защиты.
Моя попытка связаться с Cloudflare
Я не первый, кто это заметил. Я разместил детальный разбор этой проблемы на форуме Cloudflare Community .
Вот дословная выжимка в пяти актах из того треда [1b]:
Акт 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 уже является предложенным стандартом. Заключаю: “Единственный логичный вывод… в том, что отказ от поддержки RFC 8657 — это бизнес-решение”.
Акт 4 ():
grey: “Обожаю разговаривать сам с собой в этом треде :grinning_face:”(Мое опровержение остается без ответа. Тег “Решение” остается на неправильном ответе.)Акт 5 ():
Эта тема была автоматически закрыта через 2 дня после последнего ответа. Новые ответы больше не допускаются.
Критическая брешь безопасности, о которой сообщил пользователь, с 1.3 тыс. просмотров и 20 лайками, не была должным образом “решена”. Она была автоматически закрыта роботом.
Чтобы привлечь к этому больше внимания, я также опубликовал статью на популярном российском техническом сайте Хабр [20] , которая стала лучшим постом недели. Это показывает, что сообщество понимает проблему, даже если процесс поддержки Cloudflare спроектирован так, чтобы её игнорировать.
Главное противоречие: бизнес-решение, а не техническое отставание
Член команды Cloudflare заявил, что это не уязвимость и что они будут соблюдать стандарт, “если RFC 8657 будет принят”.
Этот ответ, на мой взгляд, лукав.
- RFC 8657 был опубликован в . Это стандарт уже шесть лет.
- У Cloudflare есть
долгая история
внедрения критических протоколов безопасности, таких как TLS 1.3 [21] и QUIC [22], когда они еще были в статусе черновика.
Утверждать, что им нужно “подождать” этого стандарта, противоречит всей их инновационной культуре. Это не техническое отставание; это бизнес-решение.
Когда mmalden из команды Cloudflare ответил, они заявили, что будут соблюдать стандарт, “если RFC 8657 будет принят”. Этот ответ — официально помеченный как “Решение” треда — демонстративно ложен и противоречит собственной инженерной истории Cloudflare.
Как я указал в своем опровержении команде:
- Стандарт уже “принят”: RFC 8657 уже является Предложенным Стандартом (Proposed Standard) на треке стандартизации IETF.
- Статус “черновика” не оправдание: У Cloudflare есть
долгая история
внедрения протоколов за годы до их финализации.
В своем блог-посте о QUIC Cloudflare явно хвасталась этой культурой: “Команда системной инженерии Cloudflare имеет долгую историю инвестирования времени и усилий в тестирование новых технологий, часто до того, как эти технологии будут стандартизированы или приняты где-либо еще”
. [24b]
Но в случае со стандартом RFC 8657, закрывающим критическую дыру в безопасности, они утверждают, что должны дождаться окончания бюрократических процедур?
Более того, команда предложила полагаться на логи Certificate Transparency (CT) как средство смягчения. Как я им объяснил, CT-логи — это инструмент обнаружения, а не предотвращения. Они предупредят вас после того, как злоумышленник уже выпустил мошеннический сертификат и перехватил ваш трафик. Это классическая слабость CWE-1188.
Это подтверждает, что отсутствие поддержки — не технический недосмотр или вопрос стандартов. Вероятно, это сознательное бизнес-решение сохранить “бесплатный” продукт уязвимым, закрывая безопасные CAA-записи за платными планами.
Что следует сделать (Решение не сложное)
Cloudflare, которая обеспечивает работу огромной части веба (20.4% всех сайтов) и занимает доминирующую долю 81.6% среди провайдеров обратного прокси, должна сделать следующее: [27] [28]
Источник: Statista — Инфографика. Больше инфографики на Statista.
- Сделать Universal SSL безопасным по умолчанию: Прекратить внедрение разрешающих записей. Вместо этого внедрять ограничивающие записи с использованием
accounturiдля собственных внутренних ACME-аккаунтов Cloudflare. Это даст пользователям лучшее из двух миров: они защищены по умолчанию, и если они добавят свою записьaccounturi, обе будут валидными (их и Cloudflare), но не запись злоумышленника. - Обеспечить полный контроль пользователя: Обновить логику DNS. Если пользователь определяет запись для
letsencrypt.org, не внедрять дублирующую разрешающую запись для того же CA. Доверяйте своему пользователю. Это простоеif (user_record_exists) { do_not_inject } - Быть прозрачными: Обновить документацию [7b], чтобы явно объяснять это поведение переопределения и создаваемые им риски, вместо того чтобы прятать это в мелком шрифте.
Что можно сделать прямо сейчас?
Пока 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-записи.
- Требования: Функция загрузки собственных сертификатов (Custom Certificates) доступна только на тарифах Business и Enterprise.
- Примечание про Advanced Certificate Manager (ACM): Хотя платное дополнение ACM позволяет заказывать определенные сертификаты на младших тарифах, процессом их выпуска все равно управляет Cloudflare. Следовательно, использование ACM может не защищать от автоматического перекрытия CAA-записей.
- Для всех остальных (Free/Pro): Агрессивный мониторинг CT: Если переход на тариф Business невозможен, вам придется полагаться на обнаружение, а не на предотвращение. Настройте строгий мониторинг Certificate Transparency (CT) (используя инструменты вроде
certstreamили встроенные уведомления Cloudflare). Если вы заметите выпуск сертификата для вашего домена, который вы не инициировали (даже если он выпущен легитимным CA, например Let’s Encrypt), рассматривайте это как инцидент безопасности.
Я надеюсь, что при достаточном внимании сообщества мы сможем убедить Cloudflare закрыть эту брешь для всех, а не только для платящих клиентов.
Спасибо, что уделили время прочтению! Надеюсь, это было полезно.
