A Hole in Cloudflare's Shield: How the Jabber.ru Attack Exposed a Problem Kept Silent Since 2023

Many remember the incident from two years ago involving a Man-in-the-Middle attack on the XMPP service jabber.ru. This story created significant noise, but the primary lesson was not absorbed by the broader audience. The attack revealed a systemic vulnerability in TLS certificate issuance that directly affects millions of websites — particularly those trusting Cloudflare for security.

The author raised this issue on the Cloudflare forum 23 days prior to publication but received no response, similar to other comparable requests. This article aims to explain the problem clearly.

Incident Analysis: Jabber.ru

For several months — at least from July through October 2023 — all traffic to Russia's largest XMPP server was intercepted and decrypted. Attackers obtained fully valid TLS certificates from Let's Encrypt for the domains jabber.ru and xmpp.ru.

This was not a server breach. The attack occurred at the network level through hosting providers — Hetzner and Linode. Threat actors (allegedly state-sponsored for lawful interception purposes) reconfigured routing so that all traffic intended for jabber.ru servers, including domain validation requests from Let's Encrypt, passed through their infrastructure.

By intercepting validation requests (likely http-01 or tls-alpn-01 methods), they successfully proved domain control to Let's Encrypt and obtained legitimate certificates. Detection occurred accidentally when one fraudulent certificate expired and wasn't renewed promptly, causing user connection errors.

The core vulnerability lies in the basic domain validation mechanism — not in the XMPP protocol or Let's Encrypt itself.

Technical Background: CAA and RFC 8657

Although network-level traffic interception seems insurmountable, protection exists through Certification Authority Authorization (CAA), described in RFC 8659. This simple DNS record states: "Only this Certificate Authority may issue certificates for my domain."

# Allow only Let's Encrypt
example.com. IN CAA 0 issue "letsencrypt.org"

However, as the jabber.ru case demonstrated, this proves insufficient since attackers used an authorized CA. Post-incident analysis by engineer Hugo Landau revealed that RFC 8657, proposed in 2019, could have prevented such attacks. This standard extends CAA with two critical parameters:

1. accounturi

This parameter binds certificates to a specific Certificate Authority account — a "second factor" for certificate issuance. Your Let's Encrypt account URI is a unique identifier.

# Allow Let's Encrypt ONLY from account ID 12345678
example.com. IN CAA 0 issue "letsencrypt.org;
account uri=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Even if attackers intercept traffic, they cannot obtain certificates because their request comes from a different Let's Encrypt account. Let's Encrypt has supported this standard since January 2021. The CA verifies the accounturi against your CAA record and refuses issuance upon mismatch.

2. validationmethods

This parameter restricts which validation methods the CA may use for domain ownership verification.

# Allow Let's Encrypt ONLY through DNS validation
example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

Since the jabber.ru attack exploited network traffic interception, limiting validation to dns-01 (which requires DNS zone modifications rather than traffic control) would have significantly complicated the attack. Using DNSSEC alongside this would make it practically impossible.

3. Combined Protection

# Maximum security
example.com. IN CAA 0 issue "letsencrypt.org;
validationmethods=dns-01;
accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Hugo Landau stated in his incident analysis that, based on known attack details, deploying this extension would have prevented the jabber.ru compromise.

The Elephant in the Room: Cloudflare's Role

Here is the critical issue: Cloudflare, as an internet infrastructure leader, does something peculiar with its Universal SSL service — mandatory for free accounts. When enabled, Cloudflare automatically adds CAA records for its partner CAs (Let's Encrypt, Google Trust Services, etc.) to your DNS zone.

The records look like this:

# Standard certificate records (issue)
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "pki.goog; cansignhttpexchanges=yes"
example.com. IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes"
example.com. IN CAA 0 issue "comodoca.com"
example.com. IN CAA 0 issue "ssl.com"

# Wildcard certificate records (issuewild)
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 issuewild "pki.goog; cansignhttpexchanges=yes"
example.com. IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"
example.com. IN CAA 0 issuewild "comodoca.com"
example.com. IN CAA 0 issuewild "ssl.com"

The Problem: None of these records use accounturi, and Cloudflare does not allow users to override them. This leaves the same security gap that affected jabber.ru. Cloudflare effectively states: "Any Let's Encrypt account can obtain certificates for this domain if validation passes."

Your stricter CAA record with accounturi for non-proxied servers becomes nearly useless. Per CAA processing rules, if any permissive record lacks accounturi, CAs may issue for any account. Manually entering Cloudflare records with accounturi won't work — Cloudflare ignores user-added records and keeps its own. Disabling Universal SSL requires a paid plan.

Cloudflare not only ignores modern security standards but actively prevents users from implementing them independently, negating the purpose of RFC 8657.

Conclusions and Recommendations

The situation is currently stalled. Modern, CA-supported standards exist to solve documented problems, yet the largest infrastructure provider ignores them and creates risks for millions of users.

For users:

• Audit your DNS records. Check your CAA entries. If you are using Cloudflare's Universal SSL, you remain vulnerable to jabber.ru-type attacks.
• Demand change. Support the Cloudflare community forum discussion. Greater attention increases the likelihood of resolution — previous requests were ignored.
• Consider alternatives. For critical projects, move away from Universal SSL toward manual certificate management and full CAA control elsewhere.

What Cloudflare should do:

• Implement accounturi and validationmethods for all Universal SSL certificates immediately, benefiting all users by default.
• Provide full CAA record management, allowing users to add their own records that coexist properly with Cloudflare's entries.
• Update documentation to honestly address current risks and how CAA is handled.

Closing this gap now is far better than managing the consequences later — as jabber.ru administrators learned the hard way.