Addressing the Unauthorized Issuance of Multiple Tls Certificates for 1.1.1.1

It's interesting to imagine how you'd maliciously use a TLS certificate for a major DoH provider (which does NOT appear to have happened here). Impersonating a DoH server would let you return any DNS responses you wish. DNSSEC would only protect against this sort of attack if the stub resolver performed the DNSSEC validation, which I think is quite rare. For HTTPS, the attacker would also need a certificate for the target domain (or trick the user into trusting an invalid certificate / downgrade to HTTP). This is not a compelling attack since it only compromises one layer of protection.

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.

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:

    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."

It seems like all Cloudflare does these days is write up apologies for security incidents.