Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1(blog.cloudflare.com)
blog.cloudflare.com
Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1
https://blog.cloudflare.com/unauthorized-issuance-of-certificates-for-1-1-1-1/
5 comments
From a privacy perspective, the impact is further limited by the tiny number of popular zones that are actually signed --- you're two predicates removed from a useful attack (widespread deployment of clientside DNSSEC validation, which is very rare today, and widespread zone signing).
It's a weird misissuance from that perspective! Suggestive to me of something nonmalicious (nonmalicious misissuance is still a dealbreaker).
It's a weird misissuance from that perspective! Suggestive to me of something nonmalicious (nonmalicious misissuance is still a dealbreaker).
Sounds like HackerOne Managed Triage Services dropped the ball again and closed both reports without even flagging to Cloudflare's security engineers.
This happened in a high-profile way with the Zendesk situation (https://news.ycombinator.com/item?id=41818459) and is not the first time:
Timeline of events:
https://blog.cloudflare.com/unauthorized-issuance-of-certifi...
>2025-09-02 04:50:00: Report shared with us on HackerOne, but was mistriaged
>2025-09-03 02:35:00: Second report shared with us on HackerOne, but also mistriaged.
>2025-09-03 10:59:00: Report sent on the public mailing [list] picked up by the team.
---
The canned response in question:
https://groups.google.com/g/certificate-transparency/c/we_8S...
>"after reviewing your submission it appears this behavior does not pose a concrete and exploitable risk to the platform in and on itself.
>If you're able to demonstrate any impact please let us know, and provide an accompanying working exploit."
This happened in a high-profile way with the Zendesk situation (https://news.ycombinator.com/item?id=41818459) and is not the first time:
1. Bug bounty report received from knowledgeable person who isn't a "celebrity" (top x performer on H1 leaderboard, social media influencer, H1 event invitee)
2. with novel impact to the company, open source ecosystem, or wider Internet
3. which doesn't fall neatly into an OWASP Top 10 (Web) box
4. so Triage close it in the pre-queue before the company get eyes on it, replying with a zero-effort CR (Common Response aka Canned Response)
5. the company doesn't see the report unless they go digging for it in the thousands of spam/bullshit/Acunetix copypaste reports that are also closed
---Timeline of events:
https://blog.cloudflare.com/unauthorized-issuance-of-certifi...
>2025-09-02 04:50:00: Report shared with us on HackerOne, but was mistriaged
>2025-09-03 02:35:00: Second report shared with us on HackerOne, but also mistriaged.
>2025-09-03 10:59:00: Report sent on the public mailing [list] picked up by the team.
---
The canned response in question:
https://groups.google.com/g/certificate-transparency/c/we_8S...
>"after reviewing your submission it appears this behavior does not pose a concrete and exploitable risk to the platform in and on itself.
>If you're able to demonstrate any impact please let us know, and provide an accompanying working exploit."
My HackerOne dismissal reads
"Although your finding might appear to be a security vulnerability, after reviewing your submission it appears this behavior does not pose a concrete and exploitable risk to the platform in and on itself. If you're able to demonstrate any impact please let us know, and provide an accompanying working exploit."
I was disappointed, and as far as I'm concerned, HackerOne is 2/2 dismissals.
"Although your finding might appear to be a security vulnerability, after reviewing your submission it appears this behavior does not pose a concrete and exploitable risk to the platform in and on itself. If you're able to demonstrate any impact please let us know, and provide an accompanying working exploit."
I was disappointed, and as far as I'm concerned, HackerOne is 2/2 dismissals.
It seems like all Cloudflare does these days is write up apologies for security incidents.
This is problematic for SMTP/email, as you really need a trustworthy MX response and, unless you have MTA-STS, TLS validation is usually not performed. DNSSEC/DANE could help, but it depends on where DNSSEC validation occurs.
It would, however, be a privacy concern as the attacker impersonating the DoH server would learn the queries and source IP addresses.