--- draft: false version: "2.2" title: "CVE-2026-14440: как Cloudflare Universal SSL обходит строгие CAA-ограничения RFC 8657" description: "CVE-2026-14440: как Cloudflare Universal SSL может перекрывать строгие CAA-ограничения RFC 8657 и ослаблять контроль выпуска сертификатов." abstract: "В этой статье анализируется 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-сертификата, которому доверяют браузеры, и атаке посредника против затронутого домена." backstory: "Расследование началось, когда я попытался усилить домены на 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, указав Давида Осипова как независимого исследователя." publishDate: "2025-12-31T09:44:00Z" modifiedDate: "2026-07-08T12:11:00Z" doi: "10.5281/zenodo.21261469" conceptDoi: "10.5281/zenodo.18201411" securityIdentifiers: - type: "CVE" id: "CVE-2026-14440" url: "https://www.cve.org/CVERecord?id=CVE-2026-14440" - type: "GHSA" id: "GHSA-vrv9-rjp4-w93c" url: "https://github.com/advisories/GHSA-vrv9-rjp4-w93c" - type: "NotCVE" id: "NotCVE-2026-0001" url: "https://notcve.org/view.php?id=NotCVE-2026-0001" - type: "CWE" id: "CWE-693" url: "https://cwe.mitre.org/data/definitions/693.html" - type: "EUVD" id: "EUVD-2026-41207" url: "https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-41207" - type: "Positive Technologies DB" id: "PT-2026-54701" url: "https://dbugs.ptsecurity.com/vulnerability/PT-2026-54701" - type: "Wikidata" id: "Q140402353" url: "https://www.wikidata.org/entity/Q140402353" cover: "./images/cloudflare_vulnerability_RFC 8657.jpg" coverAlt: "Поверженный раненый рыцарь в доспехах держит большой щит с логотипом Cloudflare, пробитый пулей." coverLicense: "https://creativecommons.org/licenses/by/4.0/" coverCreator: "https://david-osipov.vision/ru/about/#person" coverCopyrightHolder: "https://david-osipov.vision/ru/about/#person" coverCopyrightNotice: "© 2025 David Osipov. Лицензировано по CC BY 4.0." hub: "Кибербезопасность" tier: "Брифинг" license: "https://creativecommons.org/licenses/by/4.0/" keywords: ["dns", "caa", "rfc-8657", "cloudflare", "mitm", "анализ-безопасности", "lets-encrypt", "продвинутый-пользователь", "архив", "bgp-хайджекинг", "rfc-8659", "valdikss", "jabber.ru", "http-01", "dns-01"] keywordsEn: ["dns", "caa", "rfc-8657", "cloudflare", "mitm", "security-analysis", "lets-encrypt", "advanced-user", "archive", "bgp-hijacking", "rfc-8659", "valdikss", "jabber.ru", "http-01", "dns-01"] sharedContent: - '@type': AudioObject url: "https://media.david-osipov.vision/2023-jabber-attack-exposes-critical-cloudflare-flaw-in-2026.opus" contentUrl: "https://media.david-osipov.vision/2023-jabber-attack-exposes-critical-cloudflare-flaw-in-2026.opus" encodingFormat: "audio/ogg;codecs=opus" duration: "PT34M21S" name: "Аудиопрезентация: Атака на jabber.ru (2023) вскрывает критическую уязвимость Cloudflare в 2026 году. Пока на английском языке." description: "Аудио-обзор того, как Cloudflare Universal SSL ослабляет защиту по RFC 8657." license: "https://creativecommons.org/licenses/by/4.0/" contentSize: "8.30 MiB" bitrate: "33.8 kb/s" uploadDate: "2026-01-05T00:00:00Z" inLanguage: "en" associatedArticle: "https://david-osipov.vision/ru/blog/cloudflare-ssl-mitm-flaw-2026/" isBasedOn: "https://david-osipov.vision/ru/blog/cloudflare-ssl-mitm-flaw-2026/" creator: '@id': "https://david-osipov.vision/ru/about/#person" sources: - url: "https://media.david-osipov.vision/2023-jabber-attack-exposes-critical-cloudflare-flaw-in-2026.opus" encodingFormat: "audio/ogg;codecs=opus" - '@type': VideoObject url: "https://www.youtube.com/watch?v=w09rF75f_vo" contentUrl: "https://www.youtube.com/watch?v=w09rF75f_vo" embedUrl: "https://www.youtube-nocookie.com/embed/w09rF75f_vo" duration: "PT7M28S" uploadDate: "2026-01-05T00:00:00Z" name: "Брешь в защите Cloudflare: Как атака на jabber.ru в 2023 году вскрывает критическую уязвимость в 2026" description: "Видео-обзор разрыва в валидации CAA в Cloudflare и уязвимости для MitM-атак." license: "https://creativecommons.org/licenses/by/4.0/" inLanguage: "en" associatedArticle: "https://david-osipov.vision/ru/blog/cloudflare-ssl-mitm-flaw-2026/" isBasedOn: "https://david-osipov.vision/ru/blog/cloudflare-ssl-mitm-flaw-2026/" creator: '@id': "https://david-osipov.vision/ru/about/#person" semanticTags: - label: "Cloudflare" url: "https://ru.wikipedia.org/wiki/Cloudflare" wikipedia: ru: "https://ru.wikipedia.org/wiki/Cloudflare" wikidata: "Q4778915" - label: "CVE-2026-14440" url: "https://www.cve.org/CVERecord?id=CVE-2026-14440" wikidata: "Q140402353" - label: "Let's Encrypt" url: "https://en.wikipedia.org/wiki/Let%27s_Encrypt" wikipedia: ru: "https://ru.wikipedia.org/wiki/Let's_Encrypt" wikidata: "Q18786919" - label: "RFC 8657" url: "https://doi.org/10.17487/RFC8657" wikipedia: ru: "https://ru.wikipedia.org/wiki/Certification_Authority_Authorization" wikidata: "Q77250380" - label: "Border Gateway Protocol" url: "https://en.wikipedia.org/wiki/Border_Gateway_Protocol" wikipedia: ru: "https://ru.wikipedia.org/wiki/Border_Gateway_Protocol" wikidata: "Q11155" - label: "Man-in-the-middle Attack" url: "https://ru.wikipedia.org/wiki/Атака_посредника" wikipedia: ru: "https://ru.wikipedia.org/wiki/Атака_посредника" wikidata: "Q554830" - label: "Government hacking" url: "https://en.wikipedia.org/wiki/Government_hacking" wikipedia: en: "https://en.wikipedia.org/wiki/Government_hacking" wikidata: "Q60761004" - label: "Cloudflare Universal SSL" url: "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/" wikidata: "Q140459847" faq: enabled: true title: "Часто задаваемые вопросы о CVE-2026-14440, Cloudflare Universal SSL, CAA и RFC 8657" wrapInDetails: true summary: "Развернуть вопросы и ответы об уязвимости, рисках, реалистичном атакующем, снижении риска и истории раскрытия" maxItems: 20 items: - question: "Что такое CVE-2026-14440?" answer: "CVE-2026-14440 — это уязвимость Cloudflare Universal SSL / CAA / RFC 8657. На затронутых зонах Universal SSL авторитетный DNS Cloudflare может на момент запроса отдавать автоматически управляемый CAA RRset, который перекрывает CAA-записи владельца домена. В результате ограничения RFC 8657 accounturi или validationmethods не применяются сквозно." - question: "Это означает, что Cloudflare взломали?" answer: "Нет. Это не взлом Cloudflare. Публичные записи не подтверждают активную эксплуатацию против клиентов Cloudflare. В истории изменений NVD видно, что CISA-ADP изменила значение SSVC exploitation с none на poc; это поддерживает формулировку «есть доказательство концепции», но не утверждение, что атаки уже идут. Это сбой защитного механизма: автоматическое управление CAA в Universal SSL конфликтует с пользовательскими CAA-ограничениями RFC 8657." - question: "Кого это затрагивает?" answer: "Затронутый продукт — Cloudflare Universal SSL в облачном сервисе Cloudflare. Практический риск прежде всего важен для владельцев зон, которые хотят полноценную предотвращающую защиту от несанкционированного выпуска сертификатов через RFC 8657 accounturi и/или validationmethods, пока Universal SSL остаётся включённым." - question: "Кто может реалистично воспользоваться этой уязвимостью?" answer: "Реалистичный атакующий — это сетевой актор, а не обычный веб-злоумышленник. Ему нужен ACME-аккаунт в одном из центров сертификации из отдаваемого CAA RRset, и он должен пройти проверку контроля домена с нескольких географически независимых сетевых точек, используемых в MPIC. На практике это указывает на государственного или терпимого государством сетевого актора, крупного провайдера или транзитного оператора, либо на сложного BGP/маршрутного атакующего с достаточно широким контролем, чтобы повлиять на несколько точек проверки." - question: "Делает ли MPIC эту уязвимость неважной?" answer: "Нет. 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 и реального поведения маршрутизации." - question: "Чему остаётся подвержен затронутый домен?" answer: "Если зона полагается на ограничения RFC 8657 accounturi или validationmethods, но остаётся в уязвимом режиме автоматического управления CAA в Universal SSL, эти ограничения не защищают выпуск сертификатов сквозно. Эксплуатация всё равно нетривиальна: атакующему нужен ACME-аккаунт в одном из центров сертификации из отдаваемого CAA RRset, и он должен пройти проверку контроля домена сразу с нескольких географически независимых сетевых точек, используемых в MPIC. Если эти условия выполнены, возможна выдача TLS-сертификата, которому доверяют браузеры, и атака посредника против затронутого домена." - question: "Зачем нужны accounturi и validationmethods?" answer: "RFC 8657 позволяет владельцу домена ограничить выпуск сертификатов конкретным ACME-аккаунтом через accounturi и/или конкретными методами проверки через validationmethods. Эти механизмы усложняют несанкционированный выпуск сертификатов, если атакующий способен вмешаться в проверку контроля домена." - question: "Какая предотвращающая мера действительно убирает этот сценарий?" answer: "Полноценная предотвращающая защита от этого сценария требует использовать релевантные механизмы RFC 8657 — accounturi и/или validationmethods — так, чтобы центр сертификации действительно видел их в фактически отдаваемом CAA RRset. На затронутом пути Cloudflare это означает уйти из автоматического управления CAA в Universal SSL: отключить Universal SSL на затронутой зоне только после того, как уже активен другой действующий сертификат на стороне Cloudflare." - question: "Можно ли просто отключить Universal SSL?" answer: "Небезопасно, если заранее не активен другой действующий сертификат на стороне Cloudflare. Документация Cloudflare предупреждает, что отключение Universal SSL удаляет сертификат Universal SSL из сети Cloudflare, а новые TLS-соединения будут падать, если другого действующего сертификата нет." - question: "Полная защита бесплатна для клиентов Free и Pro?" answer: "Публичная документация 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 только как средством обнаружения." - question: "Мониторинг Certificate Transparency исправляет проблему?" answer: "Нет. Мониторинг CT — это видимость после выпуска, а не предотвращающий контроль. Он может показать, что сертификат существует, но не останавливает CA до выпуска, не закрывает короткое окно для MITM-атаки и не сообщает автоматически, является ли сертификат злонамеренным или обычной платформенной автоматикой. В документации Cloudflare CT Monitoring указано, что alerts по умолчанию выключены, а обычный выпуск сертификатов, backup certificates и shared certificates могут создавать уведомления. RFC 6962 прямо говорит, что CT-логи сами по себе не предотвращают ошибочную выдачу сертификатов." - question: "Почему в статье всё ещё упоминается jabber.ru?" answer: "Инцидент jabber.ru 2023 года — это прецедент класса атак: ошибочный выпуск сертификата через перехват проверки контроля домена. Это не инцидент Cloudflare и не прямой прогноз эксплуатации против зон Cloudflare с anycast, но он показывает, почему привязка к ACME-аккаунту и методу проверки по RFC 8657 важна." - question: "Какие официальные оценки серьёзности указаны в публичных записях?" answer: "Публичные записи показывают CNA CVSS v4.0 7.6 High и CISA-ADP CVSS v3.1 6.8 Medium. NVD сейчас помечает запись как Awaiting Enrichment и пока не дала собственную расширенную оценку." - question: "Означает ли значение CISA-ADP SSVC 'poc', что атака уже идёт?" answer: "Нет. В терминах SSVC значение poc означает уровень «доказательство концепции» и сигнал для приоритизации реагирования. Это не публичное доказательство активной эксплуатации против клиентов Cloudflare. В статье нельзя утверждать подтверждённую эксплуатацию в реальных атаках без прямого публичного источника." - question: "Кто обнаружил и сообщил об уязвимости?" answer: "Публичная запись NVD указывает Давида Осипова как независимого исследователя. Раскрытие координировалось через CISA/CERT/CC VINCE, а финальную CVE-запись Cloudflare опубликовала в своей зоне ответственности CNA." - question: "Что должны проверить затронутые клиенты?" answer: "Нужно проверять фактически отдаваемый CAA RRset через DNS-запросы, а не только CAA-записи, видимые в панели управления Cloudflare. Важно то, какой набор CAA-записей видит центр сертификации в момент проверки." isFeatured: true author: collection: "people" id: "david-osipov" # References for citation management references: - id: "cf-community-799999" type: "website" title: "Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA" organization: "Cloudflare Community" year: 2025 url: "https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999" archiveUrl: "https://archive.ph/v45rx" archiveDate: "2025-11-29" accessDate: "2025-11-29" - id: "valdikss-jabber" type: "article" title: "Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service" authors: ["ValdikSS"] year: 2023 month: 11 day: 3 url: "https://notes.valdikss.org.ru/jabber.ru-mitm/" archiveUrl: "https://web.archive.org/web/20251001180559/http://notes.valdikss.org.ru/jabber.ru-mitm/" archiveDate: "2025-10-01" accessDate: "2025-11-29" - id: "rfc8659" type: "rfc" title: "DNS Certification Authority Authorization (CAA) Resource Record" authors: ["Phillip Hallam-Baker", "Rob Stradling", "Jacob Hoffman-Andrews"] organization: "RFC Editor" series: "Request for Comments" number: 8659 doi: "10.17487/RFC8659" url: "https://www.rfc-editor.org/info/rfc8659" pagetotal: 17 year: 2019 month: 11 - id: "rfc8446" type: "rfc" title: "The Transport Layer Security (TLS) Protocol Version 1.3" authors: ["Eric Rescorla"] organization: "RFC Editor" series: "Request for Comments" number: 8446 doi: "10.17487/RFC8446" url: "https://www.rfc-editor.org/info/rfc8446" pagetotal: 160 year: 2018 month: 8 - id: "rfc9000" type: "rfc" title: "QUIC: A UDP-Based Multiplexed and Secure Transport" authors: ["Jana Iyengar", "Martin Thomson"] organization: "RFC Editor" series: "Request for Comments" number: 9000 doi: "10.17487/RFC9000" url: "https://www.rfc-editor.org/info/rfc9000" pagetotal: 151 year: 2021 month: 5 - id: "rfc6844" type: "rfc" title: "DNS Certification Authority Authorization (CAA) Resource Record" authors: ["Phillip Hallam-Baker", "Rob Stradling"] organization: "RFC Editor" series: "Request for Comments" number: 6844 doi: "10.17487/RFC6844" url: "https://www.rfc-editor.org/info/rfc6844" pagetotal: 18 year: 2013 month: 01 - id: "rfc8657" type: "rfc" title: "Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding" authors: ["Hugo Landau"] organization: "RFC Editor" series: "Request for Comments" number: 8657 doi: "10.17487/RFC8657" url: "https://www.rfc-editor.org/info/rfc8657" pagetotal: 11 year: 2019 month: 11 - id: "hugo-landau-xmpp" type: "website" title: "XMPP CA/jabber.ru incident" authors: ["Landau, H."] year: 2023 month: 10 day: 20 url: "https://www.devever.net/~hl/xmpp-incident" archiveUrl: "https://web.archive.org/web/20250903150526/https://www.devever.net/~hl/xmpp-incident" archiveDate: "2025-09-03" accessDate: "2025-11-08" - id: "letsencrypt-challenges" type: "documentation" title: "Challenge Types - Let's Encrypt Documentation" organization: "Let's Encrypt" archiveUrl: "https://web.archive.org/web/20251011212447/https://letsencrypt.org/docs/challenge-types/" archiveDate: "2025-10-11" url: "https://letsencrypt.org/docs/challenge-types/" accessDate: "2025-11-29" - id: "birge-lee-2018-bgp" type: "conference" title: "Bamboozling Certificate Authorities with BGP" authors: ["Birge-Lee, H.", "Sun, Y.", "Edmundson, A.", "Rexford, J.", "Mittal, P."] booktitle: "27th USENIX Security Symposium (USENIX Security 18)" publisher: "USENIX Association" address: "Baltimore, MD" pages: "833-849" isbn: "978-1-939133-04-5" month: 8 year: 2018 url: "https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee" archiveUrl: "https://web.archive.org/web/20251012064048/https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee" archiveDate: "2025-10-01" accessDate: "2025-11-30" - id: "cf-caa-docs" type: "documentation" title: "Add CAA records - Cloudflare SSL/TLS docs" organization: "Cloudflare" url: "https://developers.cloudflare.com/ssl/edge-certificates/caa-records/" archiveUrl: "https://web.archive.org/web/20251129082411/https://developers.cloudflare.com/ssl/edge-certificates/caa-records/" archiveDate: "2025-11-29" accessDate: "2025-11-08" - id: "cf-disable-universal-ssl" type: "documentation" title: "Disable Universal SSL certificates" organization: "Cloudflare" url: "https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/disable-universal-ssl/" accessDate: "2026-07-04" - id: "cf-advanced-certificates" type: "documentation" title: "Advanced certificates" organization: "Cloudflare" url: "https://developers.cloudflare.com/ssl/edge-certificates/advanced-certificate-manager/" accessDate: "2026-07-04" - id: "cf-custom-certificates" type: "documentation" title: "Custom certificates" organization: "Cloudflare" url: "https://developers.cloudflare.com/ssl/edge-certificates/custom-certificates/" accessDate: "2026-07-04" - id: "cf-ssl-features-plans" type: "documentation" title: "Features and plans" organization: "Cloudflare" url: "https://developers.cloudflare.com/ssl/reference/all-features/" accessDate: "2026-07-04" - id: "cf-community-758109" type: "website" title: "Cloudflare nameservers ignore CAA record validationmethods and accounturi" organization: "Cloudflare Community" year: 2025 url: "https://community.cloudflare.com/t/cloudflare-nameservers-ignore-caa-record-validationmethods-and-accounturi/758109" archiveUrl: "https://archive.ph/Yiizx" archiveDate: "2025-11-30" accessDate: "2025-11-08" - id: "vercel-caa" type: "documentation" title: "Working with DNS" organization: "Vercel" url: "https://vercel.com/docs/domains/working-with-dns" archiveUrl: "https://web.archive.org/web/20250612154059/https://vercel.com/docs/domains/working-with-dns" archiveDate: "2025-06-12" accessDate: "2025-11-30" - id: "aws-caa" type: "documentation" title: "Set up to use AWS Certificate Manager" organization: "AWS" url: "https://docs.aws.amazon.com/acm/latest/userguide/setup.html#setup-caa" archiveUrl: "https://web.archive.org/web/20250729205005/https://docs.aws.amazon.com/acm/latest/userguide/setup.html#setup-caa" archiveDate: "2025-07-29" accessDate: "2025-11-30" - id: "gcloud-caa-troubleshoot" type: "documentation" title: "Troubleshoot certificate issuance - Google Cloud" organization: "Google Cloud" url: "https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#caa" accessDate: "2026-01-17" archiveUrl: "https://web.archive.org/web/20260117152905/https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#caa" archiveDate: "2026-01-17" - id: "dnssimple-support" type: "website" title: "CAA Record Format and Policy Tags" organization: "DNSimple Support" year: 2025 url: "https://support.dnsimple.com/articles/caa-record-format/" accessDate: "2025-11-08" - id: "aws-route53-caa" type: "website" title: "Amazon Route 53 now supports CAA records" organization: "AWS" year: 2017 month: 8 url: "https://aws.amazon.com/about-aws/whats-new/2017/08/amazon-route-53-now-supports-caa-records/" accessDate: "2025-11-08" - id: "wiki-diginotar" type: "website" title: "DigiNotar - Wikipedia" organization: "Wikipedia" url: "https://en.wikipedia.org/wiki/DigiNotar" accessDate: "2025-11-08" - id: "sslmate-failures" type: "website" title: "Timeline of Certificate Authority Failures" organization: "SSLMate" url: "https://sslmate.com/resources/certificate_authority_failures" archiveUrl: "https://web.archive.org/web/20250917234438/https://sslmate.com/resources/certificate_authority_failures" archiveDate: "2025-09-17" accessDate: "2025-11-30" - id: "gualtieri-http01" type: "article" title: "Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt" authors: ["Gualtieri, M."] year: 2017 month: 08 day: 31 url: "https://www.mike-gualtieri.com/posts/chaining-remote-web-vulnerabilities-to-abuse-lets-encrypt" archiveUrl: "https://web.archive.org/web/20250907232526/https://www.mike-gualtieri.com/posts/chaining-remote-web-vulnerabilities-to-abuse-lets-encrypt" archiveDate: "2025-09-07" accessDate: "2025-11-08" - id: "habr-post" type: "article" title: "Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023" authors: ["Осипов, Давид"] organization: "Habr.com" year: 2025 url: "https://habr.com/ru/articles/918570/" archiveUrl: "https://web.archive.org/web/20250812005512/https://habr.com/ru/articles/918570/" archiveDate: "2025-08-12" accessDate: "2025-11-08" - id: "cf-blog-pinning-outdated" type: "article" title: "Avoiding downtime: modern alternatives to outdated certificate pinning practices" organization: "Cloudflare Blog" year: 2024 url: "https://blog.cloudflare.com/why-certificate-pinning-is-outdated/" accessDate: "2025-11-08" - id: "cf-community-758109-workaround" type: "website" title: "Cloudflare nameservers ignore CAA record... (Workaround)" authors: ["Laudian"] organization: "Cloudflare Community" year: 2025 month: 01 day: 15 url: "https://community.cloudflare.com/t/cloudflare-nameservers-ignore-caa-record-validationmethods-and-accounturi/758109/2" archiveUrl: "https://archive.ph/Yiizx" archiveDate: "2025-11-30" accessDate: "2025-11-30" - id: "birge-lee-2024-crypto-dv" type: "paper" title: "Cryptographically-Secured Domain Validation" authors: ["Birge-Lee, H.", "Cimaszewski, G. H.", "Krahenbuhl, C.", "Wang, L.", "Gable, A.", "Mittal, P."] journal: "Princeton University, Let's Encrypt" year: "2024" url: "https://secure-certificates.princeton.edu/cryptographic-domain-validation.pdf" archiveUrl: "https://web.archive.org/web/20250416050903/https://secure-certificates.princeton.edu/cryptographic-domain-validation.pdf" archiveDate: "2025-04-16" accessDate: "2026-01-17" - id: "princeton-multiva-2023" type: "paper" title: "How Effective is Multiple-Vantage-Point Domain Control Validation?" authors: ["Cimaszewski, G.", "Birge-Lee, H.", "Wang, L.", "Rexford, J.", "Mittal, P."] journal: "arXiv:2302.08000 [cs.CR]" year: 2023 month: 2 doi: "10.48550/arXiv.2302.08000" url: "https://arxiv.org/abs/2302.08000" - id: "princeton-mpic-real-bgp-2025" type: "paper" title: "A Framework to Evaluate MPIC Security using Real-World BGP Announcements" authors: ["Henry Birge-Lee", "Ari Brown", "Christine Guo", "Cyrill Krahenbuhl", "Sohom Pal", "Liang Wang", "Prateek Mittal"] year: 2025 url: "https://liangw-sec.github.io/pub/mpicmeasure.pdf" doi: "10.1145/3730567.3764495" accessDate: "2026-07-04" - id: "cabf-br-mpic" type: "report" title: "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" organization: "CA/Browser Forum" url: "https://cabforum.org/working-groups/server/baseline-requirements/requirements/" accessDate: "2026-07-04" - id: "letsencrypt-caa" type: "documentation" title: "Certificate Authority Authorization (CAA) - Let's Encrypt Documentation" organization: "Let's Encrypt" url: "https://letsencrypt.org/docs/caa/" archiveUrl: "https://web.archive.org/web/20251004144145/https://letsencrypt.org/docs/caa/" archiveDate: "2025-10-04" accessDate: "2025-11-08" year: 2023 month: 8 day: 16 - id: "mozilla-wosign-startcom-2016" type: "article" title: "Distrusting New WoSign and StartCom Certificates" authors: ["Kathleen Wilson"] organization: "Mozilla" year: "2016" month: "10" day: 24 url: "https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/" archiveUrl: "https://web.archive.org/web/20250921194325/https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/" archiveDate: "2025-09-21" accessDate: "2025-11-30" - id: "cabforum-sc067v3" type: "report" title: "Ballot SC067v3: Require domain validation and CAA checks to be performed from multiple Network Perspectives" organization: "CA/Browser Forum" year: 2024 url: "https://cabforum.org/2024/08/05/ballot-sc067v3-require-domain-validation-and-caa-checks-to-be-performed-from-multiple-network-perspectives-corroboration" archiveUrl: "https://web.archive.org/web/20251012064049/https://cabforum.org/2024/08/05/ballot-sc067v3-require-domain-validation-and-caa-checks-to-be-performed-from-multiple-network-perspectives-corroboration" archiveDate: "2025-10-12" accessDate: "2025-11-30" - id: "cf-introducing-tls13" type: "article" title: "Introducing TLS 1.3" authors: ["Nick Sullivan"] organization: "Cloudflare Blog" year: 2016 month: 09 day: 20 url: "https://blog.cloudflare.com/introducing-tls-1-3/" archiveUrl: "https://web.archive.org/web/20250823134855/https://blog.cloudflare.com/introducing-tls-1-3/" archiveDate: "2025-08-23" accessDate: "2025-11-30" - id: "cf-head-start-quic" type: "article" title: "Get a head start with QUIC" authors: ["Nick Jones"] organization: "Cloudflare Blog" year: 2018 month: 09 day: 25 url: "https://blog.cloudflare.com/head-start-with-quic/" archiveUrl: "https://web.archive.org/web/20250620064636/https://blog.cloudflare.com/head-start-with-quic/" archiveDate: "2025-06-20" accessDate: "2025-11-30" - id: "ietf-acme-dns-persist" type: "report" title: "Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation (draft-ietf-acme-dns-persist-00)" authors: ["Heurich, S.", "Birge-Lee, H.", "Slaughter, M."] organization: "IETF" year: 2025 month: 11 day: 3 url: "https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/" archiveUrl: "https://web.archive.org/web/20260117123622/https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/" archiveDate: "2026-01-17" - id: "google-group-dnssec" type: "website" title: "The Use of DNSSEC by Certificate Authorities" authors: ["Birge-Lee, H."] organization: "Server Certificate WG (CA/B Forum)" year: 2025 month: 2 day: 19 url: "https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/WNGFxQjPkPY" archiveUrl: "https://web.archive.org/web/20260117120505/https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/WNGFxQjPkPY?pli=1" archiveDate: "2026-01-17" - id: "digicert-blog-dns-persist" type: "article" title: "A New DNS Validation Method for Simplified Certificate Automation" organization: "DigiCert" year: 2025 month: 11 url: "https://www.digicert.com/blog/a-new-dns-validation-method" archiveUrl: "https://web.archive.org/web/20260117114505/https://www.digicert.com/blog/a-new-dns-validation-method" archiveDate: "2026-01-17" - id: "letsencrypt-accounturi" type: "documentation" title: "Issue certificates only to specific agent keys" organization: "Let's Encrypt Community Support" year: 2023 month: 1 url: "https://community.letsencrypt.org/t/issue-certificates-only-to-specific-agent-keys/184283" archiveUrl: "https://web.archive.org/web/20260117123907/https://community.letsencrypt.org/t/issue-certificates-only-to-specific-agent-keys/184283/5" archiveDate: "2026-01-17" - id: "netlify-caa-support" type: "website" title: "Let's Encrypt accounturi for CAA record" organization: "Netlify Support Forums" year: 2023 url: "https://answers.netlify.com/t/lets-encrypt-accounturi-for-caa-record/103453" archiveUrl: "https://web.archive.org/web/20250710081402/https://answers.netlify.com/t/lets-encrypt-accounturi-for-caa-record/103453" archiveDate: "2025-07-10" accessDate: "2026-01-17" - id: "chrome-root-policy" type: "documentation" title: "Chrome Root Program Policy, Version 1.7" organization: "Google Chrome" year: 2025 month: 7 day: 15 url: "https://googlechrome.github.io/chromerootprogram/" archiveUrl: "https://web.archive.org/web/20260106145919/https://googlechrome.github.io/chromerootprogram/" archiveDate: "2026-01-06" accessDate: "2026-01-17" - id: "gts-cps" type: "documentation" title: "Google Trust Services, Certification Practice Statement v.5.22" organization: "Google Trust Services LLC" year: 2025 month: 6 day: 25 url: "https://pki.goog/repo/cps/5.22/GTS-CPS.html" archiveUrl: "https://web.archive.org/web/20260117133043/https://pki.goog/repo/cps/5.22/GTS-CPS.html" archiveDate: "2026-01-17" accessDate: "2026-01-17" - id: "ietf-tls-esni-25" type: "report" publisher: "Internet Engineering Task Force" note: "Work in Progress" url: "https://datatracker.ietf.org/doc/draft-ietf-tls-esni/25/" authors: ["Eric Rescorla", "Kazuho Oku", "Nick Sullivan", "Christopher A. Wood"] title: "TLS Encrypted Client Hello" year: 2025 month: 6 day: 14 - id: "cf-encrypted-client-hello" type: "article" title: "Good-bye ESNI, hello ECH!" authors: ["Christopher Patton"] organization: "Cloudflare Blog" year: 2020 month: 12 day: 8 url: "https://blog.cloudflare.com/encrypted-client-hello/" archiveUrl: "https://web.archive.org/web/20250905140052/https://blog.cloudflare.com/encrypted-client-hello/" archiveDate: "2025-09-05" accessDate: "2025-11-30" - id: "statista-cloudflare-2025" type: "website" title: "Cloudflare, a hidden pillar of the internet" authors: ["Tristan Gaudiaut"] organization: "Statista" year: 2025 month: 11 day: 19 url: "https://www.statista.com/chart/35487/market-share-of-reverse-proxy-services-cloudflare/" archiveUrl: "https://web.archive.org/web/20251130143159/https://www.statista.com/chart/35487/market-share-of-reverse-proxy-services-cloudflare/?__sso_cookie_checker=failed" archiveDate: "2025-11-30" accessDate: "2025-11-30" - id: "w3techs-proxy-2025" type: "website" title: "Usage of Reverse Proxy Services for Websites, November 2025" authors: ["W3Techs.com"] organization: "W3Techs" year: 2025 month: 11 day: 1 url: "https://w3techs.com/technologies/overview/proxy/" archiveUrl: "https://archive.ph/6fkAS" archiveDate: "2025-11-30" accessDate: "2025-11-30" - id: "w3techs-cloudflare-2026" type: "website" title: "Cloudflare — W3Techs Reverse Proxy Services Usage Statistics" organization: "W3Techs" year: 2026 month: 01 day: 17 url: "https://w3techs.com/technologies/details/cn-cloudflare" archiveUrl: "https://archive.ph/oeQrL" archiveDate: "2026-01-17" accessDate: "2026-01-17" - id: "cf-venezuela-bgp" type: "article" title: "A closer look at a BGP anomaly in Venezuela" authors: ["Bryton Herdes"] organization: "Cloudflare Blog" year: 2026 month: 01 day: 6 url: "https://blog.cloudflare.com/bgp-route-leak-venezuela/" archiveUrl: "https://web.archive.org/web/20260113015221/https://blog.cloudflare.com/bgp-route-leak-venezuela/" archiveDate: "2026-01-13" accessDate: "2026-01-15" - id: "cf-community-879930" type: "website" title: "Universal SSL exposes domains to BGP leaks (re: Venezuela analysis)" organization: "Cloudflare Community" year: 2026 month: 01 day: 15 url: "https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930" archiveUrl: "https://archive.ph/uZsIM" archiveDate: "2026-01-15" accessDate: "2026-01-15" - id: "netlify-docs" type: "documentation" title: "HTTPS (SSL) | Netlify Docs" organization: "Netlify" year: 2023 url: "https://docs.netlify.com/domains-https/https-ssl/#netlify-managed-certificates" archiveUrl: "https://web.archive.org/web/20260117025839/https://docs.netlify.com/manage/domains/secure-domains-with-https/https-ssl/#netlify-managed-certificates" archiveDate: "2026-01-17" accessDate: "2026-01-17" - id: "letsencrypt-rfc8657-prod" type: "website" title: "PROD Support for RFC8657 CAA constraints" organization: "Let's Encrypt Community Support" year: 2022 url: "https://community.letsencrypt.org/t/prod-support-for-rfc8657-caa-constraints-for-accounturi-and-validationmethods/181584" archiveUrl: "https://web.archive.org/web/20260117124118/https://community.letsencrypt.org/t/prod-support-for-rfc8657-caa-constraints-for-accounturi-and-validationmethods/181584" archiveDate: "2026-01-17" accessDate: "2026-01-17" - id: "acme-lecaa" type: "website" title: "Let's Encrypt using accounturi" organization: "University of North Carolina at Charlotte" year: 2024 url: "https://acme-lecaa.charlotte.edu/" archiveUrl: "https://web.archive.org/web/20250114115101/https://acme-lecaa.charlotte.edu/" archiveDate: "2025-01-14" accessDate: "2026-01-17" - id: "gcloud-managed-certs-caa" type: "documentation" title: "Use Google-managed SSL certificates" organization: "Google Cloud" url: "https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#caa" archiveUrl: "https://web.archive.org/web/20260117152905/https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#caa" archiveDate: "2026-01-17" accessDate: "2026-01-17" - id: "cve-2026-14440-cve-org" type: "report" title: "CVE Record: CVE-2026-14440" organization: "CVE Program" year: 2026 month: 7 day: 1 url: "https://www.cve.org/CVERecord?id=CVE-2026-14440" accessDate: "2026-07-03" - id: "nvd-cve-2026-14440" type: "report" title: "CVE-2026-14440 Detail" organization: "National Vulnerability Database" year: 2026 month: 7 day: 1 url: "https://nvd.nist.gov/vuln/detail/CVE-2026-14440" accessDate: "2026-07-03" - id: "ghsa-vrv9-rjp4-w93c" type: "report" title: "GitHub Advisory Database: GHSA-vrv9-rjp4-w93c" organization: "GitHub Advisory Database" year: 2026 month: 7 day: 2 url: "https://github.com/advisories/GHSA-vrv9-rjp4-w93c" accessDate: "2026-07-03" - id: "wikidata-q140402353" type: "database" title: "CVE-2026-14440" organization: "Wikidata" year: 2026 month: 7 day: 2 url: "https://www.wikidata.org/entity/Q140402353" accessDate: "2026-07-03" - id: "notcve-2026-0001" type: "website" title: "NotCVE-2026-0001 — Cloudflare Universal SSL CAA Augmentation" organization: "NotCVE.org" year: 2026 month: 1 day: 21 url: "https://notcve.org/view.php?id=NotCVE-2026-0001" archiveUrl: "https://web.archive.org/web/20260121122026/https://notcve.org/view.php?id=NotCVE-2026-0001" archiveDate: "2026-01-21" accessDate: "2026-07-03" note: "Запись NotCVE. CVSS v3.1: 8.7 (High)." - id: "cwe-693" type: "website" title: "CWE-693: Protection Mechanism Failure" organization: "MITRE CWE" url: "https://cwe.mitre.org/data/definitions/693.html" accessDate: "2026-07-03" - id: "cert-cc-vince-840183" type: "website" title: "CERT/CC VINCE Case VU#840183" organization: "Carnegie Mellon University CERT/CC" year: 2026 month: 1 day: 21 url: "https://kb.cert.org/vince/view/840183" note: "Кейс VINCE VU#840183 — статус: Открыт." - id: "cf-blog-acme-path-vulnerability" type: "article" title: "How we mitigated a vulnerability in Cloudflare's ACME validation logic" authors: ["Hrushikesh Deshpande", "Andrew Mitchell", "Leland Garofalo"] organization: "Cloudflare Blog" year: 2026 month: 1 day: 19 url: "https://blog.cloudflare.com/acme-path-vulnerability/" archiveUrl: "https://web.archive.org/web/20260119223010/https://blog.cloudflare.com/acme-path-vulnerability/" archiveDate: "2026-01-19" accessDate: "2026-01-21" - id: "cf-ct-monitoring" type: "documentation" title: "Certificate Transparency Monitoring" organization: "Cloudflare" url: "https://developers.cloudflare.com/ssl/edge-certificates/additional-options/certificate-transparency-monitoring/" accessDate: "2026-07-08" - id: "rfc6962" type: "rfc" title: "Certificate Transparency" authors: ["Ben Laurie", "Adam Langley", "Emilia Kasper"] organization: "RFC Editor" series: "Request for Comments" number: 6962 url: "https://www.rfc-editor.org/rfc/rfc6962.html" year: 2013 month: 6 versionHistory: - version: "2.2" date: "2026-07-08" status: "current" changes: "Усилена общественно значимая подача после публикации CVE; добавлены нюансы о триаже и шуме Certificate Transparency; добавлены ссылки на Cloudflare CT Monitoring и RFC 6962; уточнено, что CT — обнаружение, а не снижение риска; чрезмерно широкая формулировка про BGP заменена более точной цепочкой риска выпуска сертификата; сравнение с jabber.ru сохранено как контекст класса атаки, а не доказательство один-в-один." - version: "2.1" date: "2026-07-04" status: "archived" changes: "Добавлен FAQ-компонент, исправлены формулировки о снижении риска, разделены предотвращение и обнаружение, описание сложности эксплуатации приведено к публичным условиям MPIC/anycast, добавлен фокус на реалистичного сетевого актора, добавлен явный раздел о том, что MPIC существенно повышает барьер, но не является абсолютной защитой, с опорой на исследования Princeton/MPIC 2023 и 2025 годов и текущие поэтапные требования CA/B Forum, прямо описано, что полноценная предотвращающая защита требует RFC 8657 accounturi/validationmethods и ухода из затронутого режима Universal SSL: через платный путь Cloudflare или миграцию к провайдеру, сохраняющему RFC 8657, устаревшие данные о статусе/серьёзности заменены публичными значениями CVE/NVD/GHSA, а неподтверждённые выводы о внутреннем мотиве Cloudflare удалены." archiveUrl: "https://web.archive.org/web/20260708120619/https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/" - version: "1.8" date: "2026-07-03" status: "archived" changes: "Статья обновлена после официальной публикации уязвимости как CVE-2026-14440 и GHSA-vrv9-rjp4-w93c. Добавлены CVE Program, NVD, GitHub Advisory Database, Wikidata Q140402353, CWE-693 и структурированный блок vulnerability metadata. NotCVE-2026-0001 сохранён как исторический идентификатор. Уточнено, что сущность уязвимости моделируется как Thing, а записи CVE/NVD/GHSA — как внешние CreativeWork/Report references. Уточнено, что Certificate Transparency monitoring является detection control, а не preventive mitigation." - version: "1.7" date: "2026-01-21" status: "archived" changes: "Интегрирована независимая валидация: NotCVE-2026-0001 (CVSS 8.7) и кейс CERT/CC VINCE VU#840183. Добавлен раздел 'Статус уязвимости' с техническими классификациями (CWE/CAPEC). Контекстуализирован патч Cloudflare от 19 января для ACME WAF bypass как независимое исправление, не связанное с проблемой CAA. Улучшено семантическими HTML-тегами для дат и элементов данных." archiveUrl: "https://web.archive.org/web/20260121202739/https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/" - version: "1.6" date: "2026-01-17" status: "archived" changes: "Добавлен анализ draft-ietf-acme-dns-persist-00 и матрица поддержки RFC 8657 по отраслям. Интегрирована дискуссия Генри Бирже-Ли о синергии DNSSEC из CA/B Forum. Уточнены механизмы привязки аккаунтов для многоклиентских платформ. Обновлены некоторые данные по состоянию на январь 2026 года." archiveUrl: "https://archive.ph/rA4bU" - version: "1.2" date: "2026-01-15" status: "archived" changes: "Добавлены отсутствующие разделы: Audio/Video Overview, историческая справка по взломам PKI, анализ MPIC и SC067v3, таблица сравнения провайдеров, детальный анализ попыток контакта с Cloudflare, историческая справка по внедрению черновиков протоколов и инструкции по защите." archiveUrl: "https://web.archive.org/web/20260117173909/https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/" - version: "1.1" date: "2026-01-15" status: "archived" changes: "Добавлен анализ утечки BGP в Венесуэле (январь 2026) как подтверждение вектора атаки. Связана новая обсуждение в комьюнити Cloudflare о требованиях поддержки RFC 8657." - version: "1.0" date: "2025-12-30" status: "archived" changes: "Первичная публикация." archiveUrl: "https://web.archive.org/web/20260103203256/https://david-osipov.vision/ru/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/" --- import ArchiveLink from '@components/ArchiveLink.astro'; import ResponsiveTable from '@components/mdx/ResponsiveTable.astro'; import SmartImage from '@components/content/SmartImage.astro'; import OptimizedImage from '@components/ui/OptimizedImage.astro'; import AudioOverview from '@components/content/AudioOverview.astro'; import VideoOverview from '@components/content/VideoOverview.astro'; import statistaCloudflareMarketShare from './images/Secondary/cloudflare-ssl-mitm-flaw-2025/statista_cloudflare_market_share.jpeg';

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

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

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

## 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-атаки. ## Аудио-обзор ## Видео-обзор ## 🚨 ОБНОВЛЕНИЕ (январь 2026): Подтверждение из Венесуэлы и связанные события ### Связанное событие: Патч обхода ACME WAF от Cloudflare (19 января) — другая уязвимость Cloudflare раскрыла и исправила отдельную уязвимость, связанную с ACME, в логике WAF, обнаруженную исследователями безопасности **FearsOff**. [cite:cf-blog-acme-path-vulnerability] Критическое различие: Это **НЕ исправление для 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 происходят постоянно, и они всегда были частью интернета. [cite:cf-venezuela-bgp] Это признание особенно важно для понимания критичности описанной в статье проблемы безопасности. Если утечки BGP — это "обычное явление" (неважно, случайные или намеренные), то сетевой уровень не может быть доверенной основой для валидации домена. Однако, как показано ниже, путь Cloudflare Universal SSL по умолчанию может не сохранять ту самую привязку к аккаунту и методу проверки из стандарта IETF (RFC 8657), которая снижает риск выпуска сертификата, когда на трафик проверки контроля домена можно повлиять на сетевом уровне. [Я открыл новую дискуссию об этом противоречии с командой Cloudflare](https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930) [cite:cf-community-879930]. ## Введение: Критическая брешь в безопасности Cloudflare Universal SSL Я обнаружил серьезную, но легко устранимую брешь в безопасности Cloudflare Universal SSL, затрагивающую миллионы пользователей. Мои попытки обсудить эту проблему напрямую с Cloudflare [cite:cf-community-799999] оказались... скажем так, безуспешными. Проблему лучше всего понять через призму MitM-атаки на jabber.ru [cite:valdikss-jabber], произошедшей в . Тогда злоумышленники с государственной поддержкой смогли перехватить трафик `jabber.ru` на сетевом уровне. Это позволило им пройти валидацию домена с помощью проверки http-01 от Let's Encrypt и получить валидный TLS-сертификат для домена. Им не потребовалось взламывать сам сервер. ## RFC 8659 и RFC 8657: объяснение стандартов CAA Чтобы понять проблему, нужно разобраться в решении. Защита от подобных атак строится на двух стандартах IETF. ### 1. Базовый стандарт: RFC 8659 (CAA) Во-первых, есть базовый стандарт CAA [cite:rfc8659], обновляющий оригинальный [cite:rfc6844]. Это можно назвать "доверием на уровне бренда". Он позволяет добавить в 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) Здесь в игру вступает [cite:rfc8657]. Опубликованный в , он был разработан *специально* для предотвращения подобных атак. Это апгрейд от "доверия на уровне бренда" к "доверию на уровне процесса". Он добавляет два критических параметра: 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[cite:hugo-landau-xmpp]. **Параметр `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 и др.) [cite:cf-caa-docs]. Эти записи не используют параметры `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`. [cite:cf-community-758109] Интегрированная платформа Vercel Схожее поведение; абстрагирует детали выпуска, часто конфликтуя со строгими политиками. [cite:vercel-caa] Интегрированная платформа Netlify Конфликт устранен. В отличие от Cloudflare, Netlify официально публикует свой ACME `accounturi`, позволяя пользователям защитить домен. [cite:netlify-docs] [cite:netlify-caa-support] Облачный провайдер AWS (ACM) Стандартное поведение. Требует `issue "amazon.com"` (только при наличии CAA), не вмешивается в записи других CA и не перезаписывает ограничения пользователя. [cite:aws-caa] Облачный провайдер Google Cloud Стандартное поведение. Требует `issue "pki.goog"` (только при наличии CAA) и уважает пользовательские ограничения. [cite:gcloud-managed-certs-caa] Чистый DNS-провайдер AWS (Route 53) Нет конфликта. Полностью поддерживает кастомные CAA записи без вмешательства. [cite:aws-route53-caa] Это показывает четкое, отраслевое разделение. "Чистые 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 [cite:birge-lee-2018-bgp] как на основную мотивацию — модель атаки, описанная там, является именно той угрозой, для смягчения которой разработан MPIC.[cite:cabforum-sc067v3] Результаты голосования показывают необычно широкое согласие: изменение поддержали крупные эмитенты и крупные потребители платформ. Категория Голоса Уровень одобрения Ключевые участники Эмитенты (CAs) 22 100% (22 За, 0 Против) Let's Encrypt, DigiCert, Sectigo, GlobalSign Потребители 4 100% (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 (Многоперспективное подтверждение выдачи) Требовать подтвержденную валидацию с нескольких независимых сетевых точек наблюдения перед выдачей. Перехват на сетевом уровне / BGP-перехват; предотвращает выдачу на основе единственной скомпрометированной точки наблюдения. RFC 8657 (Привязка аккаунта) Привязать выдачу к конкретному ACME-аккаунту и ограничить разрешенные методы валидации. Недобросовестные администраторы, скомпрометированные субаккаунты и злоупотребления делегированными/сторонними DNS-операторами. *Кратко:* MPIC существенно снижает риск, но это не панацея. Исследование Princeton/USENIX 2023 года [cite:princeton-multiva-2023] показало 88% медианной устойчивости для оцененного multi-vantage-развёртывания Let’s Encrypt против 76% у проверки из одной точки, а работа Princeton/IMC 2025 года [cite:princeton-mpic-real-bgp-2025] показала, что оптимальные MPIC-развёртывания предотвращали ошибочную выдачу сертификата более чем в 87% оцененных реальных BGP-перехватов. Точная остаточная поверхность риска зависит от DNS, RPKI, расположения точек проверки, правил кворума и реального поведения маршрутизации [cite:cabf-br-mpic]. Именно поэтому **защита на уровне идентификации** вроде привязки аккаунта RFC 8657 остаётся обязательной для высокоценных доменов. MPIC должен отсеивать самые простые локальные сетевые атаки, но он не заменяет `accounturi` и `validationmethods`. ## «Постоянный» сдвиг: уход от Cloudflare Пока Cloudflare продолжает блокировать поддержку RFC 8657, остальная индустрия фактически объявила её требованием для следующего поколения веб-безопасности. В **ноябре 2025 года** рабочая группа IETF ACME официально приняла `draft-ietf-acme-dns-persist-00` [cite:ietf-acme-dns-persist]. Этот новый черновой стандарт позволяет использовать «Постоянную валидацию DNS» — критически важную функцию для устройств IoT и мультитенантных платформ, которые не могут выполнять 90-дневные вызовы DNS. Критически важно, что **этот новый стандарт делает обязательным RFC 8657**. Он требует использования параметра `accounturi` для привязки постоянной записи DNS к конкретному аккаунту. Без этой привязки постоянная запись станет «маркером доступа», который любой злоумышленник может переиспользовать. Авторство этого черновика подчеркивает разделение в индустрии. Он был соавторства инженеров из **Fastly** и **Amazon Trust Services**—прямых конкурентов Cloudflare—наряду с исследователями из **Crosslayer Labs**. В то время как конкуренты Cloudflare активно стандартизируют использование `accounturi` для защиты своих платформ, продукт Universal SSL компании Cloudflare остается архитектурно несовместим с ним. ### Матрица поддержки RFC 8657 (2026) Следующая таблица показывает растущий разрыв между ориентированными на безопасность поставщиками и теми, которые приоритизируют устаревшие модели удобства. Организация Роль Статус Детали и доказательства Let's Encrypt CA Полная поддержка Полностью реализовано в production с января 2023. Строгие требования синтаксиса для `accounturi`. [cite:letsencrypt-accounturi] [cite:letsencrypt-rfc8657-prod] [cite:acme-lecaa] Google Trust Services CA Полная поддержка Поддерживается в соответствии с GTS CPS v5.22 (раздел 4.2.4) [cite:gts-cps]; Обязательна в Chrome Root Program Policy v1.7 для автоматизированных решений [cite:chrome-root-policy]. DigiCert CA Только для нового поколения Принято как обязательная зависимость для метода валидации «DNS-PERSIST» в черновиках ноября 2025. [cite:digicert-blog-dns-persist] Amazon Trust Services CA Черновик/Бета Соавтор черновика постоянной DNS; предлагает стандартизировать привязку для «Canonical Authorization Domain Names». [cite:ietf-acme-dns-persist] Fastly CDN / MSP Черновик/Бета Соавтор черновика постоянной DNS, сигнализирует архитектурный переход к привязке аккаунта. [cite:ietf-acme-dns-persist] Netlify Хостинг Поддерживается Доказательство реализуемости. С Netlify публикует свой `accounturi` в документации, доказывая, что поддержка на уровне платформы возможна. [cite:netlify-docs] Cloudflare CDN / MSP Нарушено Universal SSL внедряет разрешающие записи, которые переопределяют пользовательские ограничения. Пользователи должны платить за «Custom Certificates» для обхода. [cite:cf-community-758109] ### Синергия с DNSSEC Отказ от поддержки RFC 8657 вдвойне опасен, если учесть роль DNSSEC. Как отметил исследователь Henry Birge-Lee в дискуссиях с CA/Browser Forum, комбинация **CAA + DNSSEC + RFC 8657** — это единственный механизм, который позволяет выдаче сертификатов быть «полностью основанной на криптографическом доверии». [cite:google-group-dnssec]

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

— Birge-Lee et al., «Cryptographically-Secured Domain Validation» (2024) [cite:birge-lee-2024-crypto-dv] Без `accounturi`, даже подписанный DNSSEC домен уязвим, если злоумышленник может перехватить трафик валидации (как видно из инцидента в Венесуэле). Поддерживая RFC 8657, владелец домена может криптографически заблокировать выдачу на конкретный ключ аккаунта. Переопределение этих записей Cloudflare фактически понижает безопасность домена, независимо от того, использует ли он DNSSEC или нет. ## Но... Это *действительно* проблема? (Да, это так) Инцидент с `jabber.ru` — это основной, мощный кейс-стади, но веб-PKI — это кладбище похожих инцидентов, для предотвращения которых были созданы эти стандарты. * ** — Взлом DigiNotar:** Полная компрометация CA привела к выдаче мошеннических сертификатов для Google, Yahoo и других, использовавшихся для MitM-атак на государственном уровне. [cite:wiki-diginotar] [cite:sslmate-failures] `accounturi` (или даже базовый CAA) был бы защитой. * **- — WoSign и StartCom:** Этим CA отказали в доверии из-за многочисленных сбоев, включая выдачу сертификатов без надлежащей валидации. [cite:mozilla-wosign-startcom-2016] [cite:sslmate-failures] `validationmethods` предотвратил бы выдачу через нестандартные, более слабые методы. * ** — Цепочка веб-уязвимостей:** Исследователь показал, как простая уязвимость path traversal на веб-сервере может быть использована для прохождения проверки http-01. [cite:gualtieri-http01] Политика `validationmethods=dns-01` сделала бы этот целый класс атак бесполезным. * ** — Исследование BGP-перехвата (Принстон):** Фундаментальная статья Принстонского университета [cite:birge-lee-2018-bgp] продемонстрировала, как BGP-перехват может быть использован для обхода валидации http-01. Атака на `jabber.ru` была реальной реализацией этой точной модели угрозы (перехват на сетевом уровне). * **Январь 2026 — утечки маршрутов в Венесуэле:** Массовая утечка маршрутов, затронувшая CANTV (AS8048), показала, что проблемы с BGP остаются постоянной угрозой современного интернета. Хотя Cloudflare в данном случае связывает событие с ошибкой конфигурации, а не злонамеренным действием, это доказывает, что перехват трафика — обычное явление, делающее строгую привязку к аккаунту (защита, которую обеспечивает RFC 8657) обязательной, а не опциональной. [cite:cf-venezuela-bgp] В каждом случае `accounturi` или `validationmethods` обеспечили бы критический, *превентивный* уровень защиты. ## Мои попытки связаться с Cloudflare Я не первый, кто это заметил. Я разместил детальный разбор этой проблемы на форуме Cloudflare Community . Вот дословная выжимка в пяти актах из того треда [cite:cf-community-799999]: > **Акт 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 лайками, не была должным образом "решена". Она была автоматически закрыта роботом. Чтобы привлечь к этому больше внимания, я также опубликовал статью на популярном российском техническом сайте Хабр [cite:habr-post] , которая стала лучшим постом недели. Это показывает, что сообщество *понимает* проблему, даже если процесс поддержки Cloudflare спроектирован так, чтобы её игнорировать. **Обновление (15 января 2026):** Вслед за публичным признанием Cloudflare того, что утечки маршрутов BGP происходят постоянно, [cite:cf-venezuela-bgp] в контексте инцидента в Венесуэле, [я открыл новое, конкретное обсуждение на их форуме комьюнити, в котором спрашиваю, почему их SSL-продукт не сохраняет основную защиту выпуска сертификатов, которая важна, когда эти утечки могут повлиять на трафик проверки контроля домена](https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930). Вы можете поддержать этот запрос здесь: [cite:cf-community-879930]. ## Главное противоречие: продуктово-безопасностный компромисс, а не доказанный мотив Член команды Cloudflare заявил, что это не уязвимость и что они будут соблюдать стандарт, "если `RFC 8657` будет принят". Это противоречит публичной записи. RFC 8657 был опубликован в , а Cloudflare имеет долгую историю внедрения протоколов безопасности, таких как TLS 1.3 [cite:rfc8446] и QUIC [cite:rfc9000], ещё до финализации стандарта. Эта история не доказывает мотив, но она ослабляет объяснение "мы должны ждать". Более узкий и безопасный вывод такой: публичное поведение выглядит как продуктово-безопасностный компромисс, а не как документированная техническая невозможность. Когда `mmalden` из команды Cloudflare ответил, они заявили, что будут соблюдать стандарт, "если RFC 8657 будет принят". Этот ответ был официально помечен как "Решение" треда, но уже тогда противоречил статусу стандарта в IETF. Как я указал в своем опровержении команде: 1. **Стандарт уже "принят":** RFC 8657 уже является Предложенным Стандартом (Proposed Standard) на треке стандартизации IETF. 2. **Статус "черновика" не оправдание:** У Cloudflare есть долгая история внедрения протоколов *за годы* до их финализации. * **TLS 1.3:** Cloudflare анонсировала поддержку , за до финализации RFC. [cite:cf-introducing-tls13] * **QUIC:** Cloudflare поддержала его , почти за до публикации RFC. [cite:cf-head-start-quic] * **ECH:** Они поддерживают его с , несмотря на то, что он до сих пор в статусе черновика. [cite:ietf-tls-esni-25] [cite:cf-encrypted-client-hello] В своем блог-посте о QUIC Cloudflare явно хвасталась этой культурой: "Команда системной инженерии Cloudflare имеет долгую историю инвестирования времени и усилий в тестирование новых технологий, часто до того, как эти технологии будут стандартизированы или приняты где-либо еще". [cite:cf-head-start-quic] Но в случае со стандартом RFC 8657, закрывающим критическую дыру в безопасности, они утверждают, что должны дождаться окончания бюрократических процедур? Ключевой момент не в мотиве. Ключевой момент в том, что публичный путь предотвращения для многих пользователей Free/Pro оказывается платным, требует миграции или связан с операционным риском. Более того, команда предложила полагаться на логи Certificate Transparency (CT) как средство смягчения. Как я им объяснил, CT-логи — это инструмент обнаружения, а не предотвращения. Они предупредят вас после того, как злоумышленник уже выпустил мошеннический сертификат и перехватил ваш трафик. Это классическая слабость CWE-1188. Значит, спор не только о стандартах. Он о том, должен ли продукт сохранять пользовательские CAA-ограничения сквозно по умолчанию или требовать перехода на другой путь сертификатов, платную надстройку либо другого провайдера. ## Что следует сделать (Решение не сложное) Cloudflare, которая обеспечивает работу огромной части веба (по состоянию на , 21.2% всех веб-сайтов, что составляет 82.1% всех веб-сайтов, у которых известен поставщик услуг обратного прокси [cite:w3techs-cloudflare-2026], в сравнении с предыдущими отчетами о 20.4% всех сайтов с 81.6% доли рынка [cite:statista-cloudflare-2025] [cite:w3techs-proxy-2025]), должна сделать следующее:
Источник: Statista — Инфографика. Больше инфографики на Statista.
1. **Сделать Universal SSL безопасным по умолчанию:** Прекратить внедрение разрешающих записей. Вместо этого внедрять ограничивающие записи с использованием `accounturi` для собственных внутренних ACME-аккаунтов Cloudflare. Это даст пользователям лучшее из двух миров: они защищены по умолчанию, и если они добавят свою запись `accounturi`, обе будут валидными (их и Cloudflare), но не запись злоумышленника. 2. **Обеспечить полный контроль пользователя:** Обновить логику DNS. Если пользователь определяет запись для `letsencrypt.org`, не внедрять дублирующую разрешающую запись для того же CA. Доверяйте своему пользователю. Это простое `if (user_record_exists) { do_not_inject }` 3. **Быть прозрачными:** Обновить документацию [cite:cf-caa-docs], чтобы явно объяснять это поведение переопределения и создаваемые им риски, вместо того чтобы прятать это в мелком шрифте. ## Вопросы, на которые 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 от неожиданного пути выпуска [cite:cf-ct-monitoring] [cite:rfc6962]. ## Что можно сделать прямо сейчас? Пока 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 помогает найти ошибочно выпущенный сертификат уже после выпуска; он не предотвращает сам выпуск.