Hacker News Reader

Comment by sheraz | Hacker News Reader

Great news, but interesting to see that they still recommend securing individual domain names. I imagine this is for security purposes?

View on HN

Yes. Wildcard certificates are useful primarily as an alternative to manually managing many certificates. But in the age of automation (now), LE wildcard certificates are only really useful to avoid rate limits, which is 20 certificates per week per set of names.

Key compromise for a single site is much less disruptive than losing control of a key that protects hundreds or thousands of sites. Generally you want to keep your scope smaller, it's safer. Rather than blanket-verify everything. Wildcards also makes it more difficult for you to see what of your names is going through CT logs.

Caddy will support wildcard certificates, but most users will not need them, because already Caddy can obtain certificates "on demand" - dynamically, during the TLS handshake. Again, the main reason for using wildcards at this point would be to reduce pressure against LE rate limits.

A particularly desired case is Sandstorm.io, which randomly generates a subdomain every time you open a document.

Yeah, there are some edge cases where a wildcard is less secure. https://security.stackexchange.com/questions/8210/what-vulne...

It's not even about edge cases - it's just good security practice to isolate credentials as much as possible and limit their scope.

I imagine so, too. If you have N machines each serving a different site, better to have each only have a key valid for its site so there's less impact from one of them being compromised.

btw, in that scenario, even if the sites all share an IP address, you can use a TCP-level proxy that supports doing the TLS SNI exchange to determine where to send the connection on, so the proxy doesn't need any of the keys and the encryption is end-to-end.

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?

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.

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

Reply on news.ycombinator.com