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.
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
3 comments
[ 3.0 ms ] story [ 21.1 ms ] threadThis 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.
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."