Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1 | Hacker News Reader

Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1

blog.cloudflare.com

37 pointsmcpherrinm5 comments

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.

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

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

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.

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

Reply on news.ycombinator.com