Hacker News Reader

Comment by orthecreedence | Hacker News Reader

Yeah, I think that if someone hacked your DNS provider, they could add secure-payments.yourbusiness.com and start spamming people with "late payment! enter your credit card!" notices or something.

So I guess, make sure you trust your DNS provider if you're using wildcards. Or is there another exploit I'm missing?

View on HN

They would need to both hack your DNS entries and have access to the private key of the pair for which the certificate was signed. Having access to the private key probably indicates a significant hole in the site's infrastructure so that is more of a concern than DNS.

Of course such access may be easier for a disgruntled internal actor so it is a risk worth considering (and mitigating via proper separation of concerns/access).

Not sure how the availability of wildcard certs changes that scenario, if I can set the DNS record for secure-payments.yourbusiness.com then I can get a non-wildcard cert for it and get on with the spamming straight away

I think it's somewhat difficult to get a valid (CA-valid) certificate for a domain you don't own, though. At least, that's what the job of the CAs is: to verify that the certs they're issuing are for the actual owner of yourbusiness.com.

That sounds like the description of an EV or OV certificate, where the CA takes additional verification steps.

LE is all about DV certs -- you just need to control the web server at secure-payments.yourbusiness.com, and with DNS control you can aim secure-payments.yourbusiness.com anywhere

Nope, DV certs just verify that you control the domain (i.e you can place arbitrary content in a specific location). You don't need to own the domain otherwise SSL would be a lot harder for mysite.hostingcompany.com type providers.

I thought that was the case, until CloudFlare issued a cert for a subdomain of mine without a single email round-trip or even notification.

Any DNS-based validation is contingent on full DNS control, and that does mean FULL. CNAME records are absolute, if I CNAME foo to xyz then I'm trusting xyz 100%. I won't get an email round-trip or CAA ping for the certificate unless I'm looking for it, because CNAME implies that all things that apply to xyz apply to anything pointed at it. So the CAA record for xyz applies, not the CAA record for foo - it's not even valid to have any other record types for the same name as a CNAME record, and CAA resolution stops if it gets a valid response versus walking up to the domain root.

To be clear: CloudFlare issued a perfectly valid certificate for a perfectly valid use case, it just bothers me that I couldn't tell it was issued until after-the-fact by seeing it in CT logs, and couldn't have prevented it from being issued by the mechanisms that seem to be built for that.

Reply on news.ycombinator.com