DavidOsipov · July 25, 2025 09:34
diff --git a/gistfile1.txt b/gistfile1.txt
 # How the 2023 MitM Attack Reveals a Critical Security Gap in Cloudflare's Universal SSL

 <img src="https://habrastorage.org/r/w780/getpro/habr/upload_files/5a0/731/17c/5a073117c595a0da5299bf14b4136cf9.jpg" alt="A wounded knight in armor slumped in defeat, holding a large shield with the Cloudflare logo that has been pierced by a bullet hole." width="200"/>
 ## Summary

 * Cloudflare's free Universal SSL automatically adds broad [CAA records](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) (e.g., issue "letsencrypt.org") without the accounturi parameter from RFC 8657.
 * This creates the exact security gap that enabled the [jabber.ru MitM attack](https://notes.valdikss.org.ru/jabber.ru-mitm/) back in 2023, where attackers got a valid Let's Encrypt certificate because they could pass domain validation from a different LE account.
 * I have tried to get Cloudflare to address this on their [community forum](https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999) for over two months, but have been met with silence and deflection. I am hoping to raise awareness here.

 Hi everyone,

 My name is David Osipov. I am a Product Manager with a passion for cybersecurity and I am here writing to you today because 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](https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999) have been unsuccessful.

 The issue is best understood through the lens of the [jabber.ru MitM attack](https://notes.valdikss.org.ru/jabber.ru-mitm/), that took place in 2023.

 Back then, government backed attackers were able to intercept traffic for [jabber.ru](https://jabber.ru) at the network level (via Hetzner/Linode). 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.

 ## The Standard That Prevents This: RFC 8657

 There is a standard designed specifically to prevent this kind of attack: [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657) by [Hugo Landau](https://www.devever.net). It extends [CAA records](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) with a crucial parameter: accounturi.

 It's kind of a second factor for certificate issuance. Let me try to clarify a bit: a standard CAA record says: "Only Let's Encrypt can issue a certificate for my domain".

 david-osipov.vision. IN CAA 0 issue "letsencrypt.org"

 But look here: david-osipov.vision. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/MY\_ACCOUNT\_ID"

 This is an RFC 8657-compliant record, which says: "Only Let's Encrypt account, using my and only my specific account, can issue a certificate for my domain".

 Now even better (especially if you have [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) turned on):

 david-osipov.vision. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

 It says smt like: "Only Let's Encrypt account, using my and only my specific account, using only DNS validation method, can issue a certificate for my domain"

 If this had been in place for [jabber.ru](http://jabber.ru), the attackers' request from their own LE account would have been rejected by the CA, and the attack would have failed. The author of RFC 8657 (Hugo Landau) himself confirmed this [in his post](https://www.devever.net/~hl/xmpp-incident), he is also positive about my mission to convince Cloudflare.

 # The Cloudflare Problem

 Now the core issue: When you use Cloudflare's free Universal SSL, Cloudflare automatically adds CAA records for its partner CAs (Let's Encrypt, Google Trust Services, etc). These records do not use the accounturi parameter!!

 This means any ACME account at Let's Encrypt that can satisfy domain validation for your domain can be issued a valid certificate. Cloudflare is creating the same vulnerability for all its Universal SSL users that [jabber.ru](http://jabber.ru) suffered from.

 Worse, if you try to add your own, more secure CAA record with accounturi, it won't not provide protection, because CF would overwrite it, and CA will permit issuance if any of the CAA records for it match!

 # My Attempt to Engage Cloudflare

 I posted a detailed breakdown of this issue on the Cloudflare Community forum on 20 May 2025. You can read the full thread here: [Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA](https://community.cloudflare.com/t/cloudflare-nameservers-ignore-caa-record-validationmethods-and-accounturi/758109)

 After a month of silence, a Cloudflare team member responded, claiming this is not a vulnerability and that they would comply "should RFC 8657 be passed."

 This response is deeply problematic. As I pointed out in my reply, Cloudflare has a proud history of implementing critical security protocols like TLS 1.3 and QUIC while they were still in draft status. For them To claim they must wait for a Proposed Standard like RFC 8657 to be finalized is inconsistent with their own innovative culture.

 The only logical conclusion is that this is a business decision to create a security gap between the free Universal SSL and paid plans where custom certificates and CAA records are fully tweakable.

 To bring more attention to this, I also published an article on the popular Ru tech site [Habr.com](http://Habr.com), which became the top post of the week, showing that the community understands and supports this issue: [Article on Habr (in Russian, but shows community support)](https://habr.com/ru/articles/824148/)

 # What Should Be Done

 This is not a theoretical risk, it is already a demonstrated attack vector. Cloudflare, which is being used by 80% (!) of websites worldwide, should finally do the following:

 1. Secure Universal SSL by Default: Implement accounturi for all certificates it issues via Universal SSL. They know which ACME accounts they use; they just need to publish them in the CAA record.
 2. Enable Full User Control: Allow users to add their own CAA records with accounturi and validationmethods that can coexist with Cloudflare's, as the RFC allows.
 3. Be Transparent: Update their documentation to explain the risks and how their CAA records work.

 I believe that with enough community attention, we can persuade Cloudflare to close this gap for everyone, not just their paying customers.

 Thank you for taking the time to read this! I hope it was useful.

 Best regards,  
 David Osipov

 * [ISNI: 0000 0005 1802 960X](https://isni.org/isni/000000051802960X)
 * [ORCID: 0009-0005-2713-9242](https://orcid.org/0009-0005-2713-9242)
 * [VIAF: 139173726847611590332](https://viaf.org/viaf/139173726847611590332)
 * [Wiki Profile](https://en.wikipedia.org/wiki/User:David_Osipov)
	# How the 2023 MitM Attack Reveals a Critical Security Gap in Cloudflare's Universal SSL

	<img src="https://habrastorage.org/r/w780/getpro/habr/upload_files/5a0/731/17c/5a073117c595a0da5299bf14b4136cf9.jpg" alt="A wounded knight in armor slumped in defeat, holding a large shield with the Cloudflare logo that has been pierced by a bullet hole." width="200"/>
	## Summary

	* Cloudflare's free Universal SSL automatically adds broad [CAA records](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) (e.g., issue "letsencrypt.org") without the accounturi parameter from RFC 8657.
	* This creates the exact security gap that enabled the [jabber.ru MitM attack](https://notes.valdikss.org.ru/jabber.ru-mitm/) back in 2023, where attackers got a valid Let's Encrypt certificate because they could pass domain validation from a different LE account.
	* I have tried to get Cloudflare to address this on their [community forum](https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999) for over two months, but have been met with silence and deflection. I am hoping to raise awareness here.

	Hi everyone,

	My name is David Osipov. I am a Product Manager with a passion for cybersecurity and I am here writing to you today because 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](https://community.cloudflare.com/t/critical-security-gap-cloudflare-must-fully-support-rfc-8657-caa/799999) have been unsuccessful.

	The issue is best understood through the lens of the [jabber.ru MitM attack](https://notes.valdikss.org.ru/jabber.ru-mitm/), that took place in 2023.

	Back then, government backed attackers were able to intercept traffic for [jabber.ru](https://jabber.ru) at the network level (via Hetzner/Linode). 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.

	## The Standard That Prevents This: RFC 8657

	There is a standard designed specifically to prevent this kind of attack: [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657) by [Hugo Landau](https://www.devever.net). It extends [CAA records](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) with a crucial parameter: accounturi.

	It's kind of a second factor for certificate issuance. Let me try to clarify a bit: a standard CAA record says: "Only Let's Encrypt can issue a certificate for my domain".

	david-osipov.vision. IN CAA 0 issue "letsencrypt.org"

	But look here: david-osipov.vision. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/MY\_ACCOUNT\_ID"

	This is an RFC 8657-compliant record, which says: "Only Let's Encrypt account, using my and only my specific account, can issue a certificate for my domain".

	Now even better (especially if you have [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) turned on):

	david-osipov.vision. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

	It says smt like: "Only Let's Encrypt account, using my and only my specific account, using only DNS validation method, can issue a certificate for my domain"

	If this had been in place for [jabber.ru](http://jabber.ru), the attackers' request from their own LE account would have been rejected by the CA, and the attack would have failed. The author of RFC 8657 (Hugo Landau) himself confirmed this [in his post](https://www.devever.net/~hl/xmpp-incident), he is also positive about my mission to convince Cloudflare.

	# The Cloudflare Problem

	Now the core issue: When you use Cloudflare's free Universal SSL, Cloudflare automatically adds CAA records for its partner CAs (Let's Encrypt, Google Trust Services, etc). These records do not use the accounturi parameter!!

	This means any ACME account at Let's Encrypt that can satisfy domain validation for your domain can be issued a valid certificate. Cloudflare is creating the same vulnerability for all its Universal SSL users that [jabber.ru](http://jabber.ru) suffered from.

	Worse, if you try to add your own, more secure CAA record with accounturi, it won't not provide protection, because CF would overwrite it, and CA will permit issuance if any of the CAA records for it match!

	# My Attempt to Engage Cloudflare

	I posted a detailed breakdown of this issue on the Cloudflare Community forum on 20 May 2025. You can read the full thread here: [Critical Security Gap: Cloudflare Must Fully Support RFC 8657 CAA](https://community.cloudflare.com/t/cloudflare-nameservers-ignore-caa-record-validationmethods-and-accounturi/758109)

	After a month of silence, a Cloudflare team member responded, claiming this is not a vulnerability and that they would comply "should RFC 8657 be passed."

	This response is deeply problematic. As I pointed out in my reply, Cloudflare has a proud history of implementing critical security protocols like TLS 1.3 and QUIC while they were still in draft status. For them To claim they must wait for a Proposed Standard like RFC 8657 to be finalized is inconsistent with their own innovative culture.

	The only logical conclusion is that this is a business decision to create a security gap between the free Universal SSL and paid plans where custom certificates and CAA records are fully tweakable.

	To bring more attention to this, I also published an article on the popular Ru tech site [Habr.com](http://Habr.com), which became the top post of the week, showing that the community understands and supports this issue: [Article on Habr (in Russian, but shows community support)](https://habr.com/ru/articles/824148/)

	# What Should Be Done

	This is not a theoretical risk, it is already a demonstrated attack vector. Cloudflare, which is being used by 80% (!) of websites worldwide, should finally do the following:

	1. Secure Universal SSL by Default: Implement accounturi for all certificates it issues via Universal SSL. They know which ACME accounts they use; they just need to publish them in the CAA record.
	2. Enable Full User Control: Allow users to add their own CAA records with accounturi and validationmethods that can coexist with Cloudflare's, as the RFC allows.
	3. Be Transparent: Update their documentation to explain the risks and how their CAA records work.

	I believe that with enough community attention, we can persuade Cloudflare to close this gap for everyone, not just their paying customers.

	Thank you for taking the time to read this! I hope it was useful.

	Best regards,
	David Osipov

	* [ISNI: 0000 0005 1802 960X](https://isni.org/isni/000000051802960X)
	* [ORCID: 0009-0005-2713-9242](https://orcid.org/0009-0005-2713-9242)
	* [VIAF: 139173726847611590332](https://viaf.org/viaf/139173726847611590332)
	* [Wiki Profile](https://en.wikipedia.org/wiki/User:David_Osipov)