"BGP route leaks happen all of the time, and they have always been part of the Internet."[cite:cf-venezuela-bgp] This admission highlights exactly why the security gap described in this article is so critical. If BGP leaks are "common" (whether accidental or malicious), then the network layer cannot be trusted for domain validation. Yet, as detailed below, Cloudflare's Universal SSL default configuration **actively disables** the specific IETF standard (RFC 8657) designed to prevent these common BGP leaks from being weaponized to issue fraudulent certificates. [I have opened a new discussion on this specific contradiction with the Cloudflare team](https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930) [cite:cf-community-879930]. ## Introduction: A Critical Security Gap in Cloudflare's Universal SSL I have identified a significant, yet easily fixable security weakness in Cloudflare's Universal SSL that affects millions of users, and my attempts to address it directly with Cloudflare [cite:cf-community-799999] have been... well, let's call it "unsuccessful." The issue is best understood through the lens of the jabber.ru MitM attack [cite:valdikss-jabber] that took place in . At that time, government-backed attackers were able to intercept traffic for `jabber.ru` at the network level. By doing this, they could satisfy the
http-01 domain validation challenge from Let's Encrypt and were issued a valid TLS certificate for the domain. They did not need to compromise the server itself.
## RFC 8659 vs RFC 8657: The CAA Standards Explained
To understand the problem, you need to understand the solution. The defense against this attack is built on two IETF standards.
### 1. The Basic Standard: RFC 8659 (CAA)
First, there's the basic CAA standard, [cite:rfc8659], which updates the original [cite:rfc6844]. This is what you can call "brand-level trust." It lets you put a record in your DNS that says:
david-osipov.vision. IN CAA 0 issue "letsencrypt.org"accounturi and validationmethods.
**The `accounturi` parameter is your "second factor."**
It's a record that says: "Only Let's Encrypt, using my specific account, can issue a certificate for my domain."
david-osipov.vision. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/MY_ACCOUNT_ID"http-01 vs. dns-01
* **http-01 challenge:** The CA asks you to put a specific file on your web server at `http://your.domain/.well-known/acme-challenge/`. This proves you control the web server, but it's vulnerable to network-level BGP hijacking. Attackers don't need to touch your server; they just need to intercept the CA's request, which is exactly what happened to `jabber.ru`.
* **dns-01 challenge:** The CA asks you to put a specific TXT record in your DNS. This proves you control the DNS, which is almost always a more secure and separate asset from your web server.
By setting this record, you forbid the CA from using the vulnerable http-01 method entirely:
david-osipov.vision. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"dns-01 only).dns-01 challenge using a CNAME to an `acme-dns` server they don't fully control (a common, secure pattern).
* **Intended Security:** The user sets an `accounturi` record to ensure only their own ACME account can use this delegation.
* **The Cloudflare Flaw:** Cloudflare replaces user's records with its permissive issue "letsencrypt.org" record.
* **The Attack:** The (untrusted) admin of the `acme-dns` server can now use their own Let's Encrypt account to get a valid certificate for the user's domain, completely bypassing the user's `accounturi` "second factor."
## This Isn't Just Cloudflare: A Pattern of "Platform vs. Provider"
To be fair (and to be more "academic"), Cloudflare isn't the only one with this problem. This is a systemic flaw in any "integrated platform" that bundles "magic" automated SSL with hosting. The magic must override your security to function.
— Birge-Lee et al., "Cryptographically-Secured Domain Validation" (2024) [cite:birge-lee-2024-crypto-dv] Without `accounturi`, even a DNSSEC-signed domain is vulnerable if the attacker can intercept the validation traffic (as seen in the Venezuela incident). By supporting RFC 8657, a domain owner can cryptographically lock issuance to a specific account key. Cloudflare's overriding of these records effectively downgrades a domain's security posture, regardless of whether they use DNSSEC or not. ## But... Is This *Really* a Problem? (Yes, It Is) The `jabber.ru` incident is the primary, powerful case study, but the Web PKI is a graveyard of similar incidents that these standards were built to prevent. * ** - DigiNotar Breach:** A complete CA compromise led to fraudulent certificates for Google, Yahoo, and more, used for state-level MitM attacks. [cite:wiki-diginotar] [cite:sslmate-failures] `accounturi` (or even basic CAA) would have been a defense. * **- - WoSign & StartCom:** These CAs were distrusted for numerous failures, including issuing certs without proper validation. [cite:mozilla-wosign-startcom-2016] [cite:sslmate-failures] `validationmethods` would have prevented issuance via non-standard, weaker methods. * ** - Chaining Web Vulnerabilities:** A researcher showed how a simple path traversal vulnerability on a web server could be used to satisfy an"Our cryptographic DV design provides domain owners the critical capability of declaratively securing their domain names against network attacks on certificate issuance."
http-01 challenge. [cite:gualtieri-http01] A `validationmethods=dns-01` policy would have rendered this entire attack class useless.
* ** - Princeton BGP Hijacking Study:** A foundational paper from Princeton University, [cite:birge-lee-2018-bgp], demonstrated how BGP hijacking could be weaponized to defeat http-01 validation. The `jabber.ru` attack was a real-world execution of this exact threat model (network-level interception).
* **January 2026 - Venezuela Routing Leaks:** A massive route leak involving CANTV (AS8048) demonstrated that BGP misconfiguration remains a daily reality. While Cloudflare attributes this to misconfiguration, it proves that traffic interception is common. As Henry Birge-Lee argued in the Server Certificate Working Group, reliance on network perspective alone (even MPIC) is insufficient without the cryptographic guarantees of DNSSEC and account binding. [cite:cf-venezuela-bgp] [cite:google-group-dnssec]
In each case, `accounturi` or `validationmethods` would have provided a critical, *preventative* layer of defense.
## My Attempt to Engage Cloudflare
I'm not the first to notice this. I posted a detailed breakdown of this issue on the Cloudflare Community forum on .
Here is a verbatim summary in five acts from that thread [cite:cf-community-799999]:
> **Act 1 ():** I submit the request "Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA".
>
> **Act 2 ():** A Cloudflare Team member (`mmalden`) finally responds. They claim the feature isn't supported because RFC 8657 isn't fully passed (incorrect) and suggest Certificate Transparency logs as an alternative. This response is marked as the "Solution."
>
> **Act 3 ():** I post a detailed rebuttal, citing Cloudflare's history of adopting draft protocols (TLS 1.3, QUIC) years before finalization, and pointing out that RFC 8657 is *already* a proposed standard. I conclude: "The only logical conclusion... is that withholding RFC 8657 support is a business decision."
>
> **Act 4 ():**
> grey: "I really love talking with myself in this thread :grinning_face:"> (My rebuttal remains unanswered. The "Solution" tag remains on the incorrect answer.) > > **Act 5 ():** >
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.A critical, user-reported security gap, with 1.3k views and 20 likes, was not properly "resolved." It was auto-closed by a robot. To bring more attention to this, I also published an article on the popular Russian tech site Habr.com [cite:habr-post] on , which became the top post of the week. This shows the community *understands* the issue, even if Cloudflare's support process is designed to ignore it. **Update (January 15, 2026):** Following Cloudflare's public admission that
BGP route leaks happen all of the time,[cite:cf-venezuela-bgp] regarding the Venezuela incident, [I have opened a new, specific inquiry on their community forum asking why their SSL product disables the primary defense against those very leaks](https://community.cloudflare.com/t/universal-ssl-exposes-domains-to-bgp-leaks-re-venezuela-analysis/879930). You can support that request here: [cite:cf-community-879930]. ## The Core Contradiction: A Business Decision, Not a Technical Lag A Cloudflare team member claimed this is not a vulnerability and that they would comply if `RFC 8657` were passed. This response is, in my view, disingenuous. 1. **RFC 8657 was published in **. It's been a standard for six years. 2. Cloudflare has a
long historyof implementing critical security protocols like TLS 1.3 [cite:rfc8446] and QUIC [cite:rfc9000] *while they were still in draft status*. To claim they must "wait" for this standard is inconsistent with their entire innovative culture. This isn't technical lag; it's a business decision. When `mmalden` from the Cloudflare Team responded, they stated they would comply "should RFC 8657 be passed." This response—which was officially marked as the "Solution" to the thread—is demonstrably false and contradicts Cloudflare's own engineering history. As I pointed out in my rebuttal to the team: 1. **The Standard is Already "Passed":** RFC 8657 is already a Proposed Standard on the IETF standards track. 2. **The "Draft" Status is not an Excuse:** Cloudflare has a
long historyof implementing protocols *years* before they were finalized. * **TLS 1.3:** Cloudflare announced support on , before the RFC was finalized. [cite:cf-introducing-tls13] * **QUIC:** Cloudflare supported it on , nearly before the RFC was published. [cite:cf-head-start-quic] * **ECH:** They support it now since , despite it still being in draft status. [cite:ietf-tls-esni-25] [cite:cf-encrypted-client-hello] In their blog post on QUIC, Cloudflare explicitly bragged about this culture:
"The Cloudflare Systems Engineering Team has a long history of investing time and effort to trial new technologies, often before these technologies are standardised or adopted elsewhere."[cite:cf-head-start-quic] Yet, for RFC 8657 standard that closes a critical security hole, they claim they must wait for bureaucracy? Furthermore, the team suggested reliance on Certificate Transparency (CT) logs as a mitigation. As I explained to them, CT logs are a detection tool, not a prevention tool. They alert you after the attacker has already issued a fraudulent certificate and intercepted your traffic. This is a classic CWE-1188 weakness. This confirms that the lack of support is not a technical oversight or a standards issue. It might be a conscious business decision to keep the "free" product vulnerable while gating secure CAA records behind paid plans. ## What Should Be Done (The Fix is Not Complicated) Cloudflare, which powers a massive portion of the web (as of ,
21.2% of all websites, representing 82.1% of all websites whose reverse proxy service is known[cite:w3techs-cloudflare-2026], compared to prior reports of 20.4% of all sites with 81.6% market share [cite:statista-cloudflare-2025] [cite:w3techs-proxy-2025]), should do the following: