Please stop advocating wildcard certificates.

Ever since I started “doing the computer stuff” I’ve been a bit wary of SSL/TLS.
It’s very easy to get wrong and revocation is not a solved problem no matter which security vendor is trying to push for sales.

There is, however, a strong urge to do things as easily as possible. For most people using SSL/TLS this becomes:

Some of these steps are worse than others, there’s almost no risk of using old openssl commands (except smaller keysize), but if you have an old list of cipher suites you’ll probably be using a deprecated cipher- and your clients data may be vulnerable in transit.

The worst one by far is the wildcard certificate; and this is for mostly obvious reasons- which is why I advocate LetsEncrypt, it doesn’t allow you to fuck up any of the steps I listed above.

Or, at least LetsEncrypt ensures it’s not as easy to screw up.

#1 Inability to revoke SSL certificates. #

Revoking SSL certificates is, as I said, not a solved problem, you can do certain things to mitigate the risk of a leak, but that’s all you’re doing and there are known working attacks against the revocation system [pdf]

#2 Ability to ‘verify’ any subdomain. #

So, a good example is when I signed on to my last job. We had a wildcard certificate for *.company.com, we also had an EV certificate on checkout.company.com where we handled credit card data.

The servers which held the wildcard certificate were considered significantly less of a security risk than the machines holding the EV cert, but the consequences would have been the same for us- to users the green bar is gone but the site will have a padlock just as any other.- If our wildcard cert was compromised not only could our site be impersonated but our checkout with a different cert could too.

If you absolutely must do wildcard certificates, please at least use a domain that is not used for anything else.

But Jan, we can mitigate these issues! … #

“We use it on a seperate namespace, so your argument is invalid”

Cool, but you still have the problem of one service impersonating another, you’ve increased your attack scope, and, if it’s a shared SSL cert and you’ve made it a bigger target.

Additionally, if you’ve copied out the certificate for different services, then you’ve got to manually replace each one.

“We have too many subdomains!”

Well, I would say “don’t do that thing”. You can easily architect your application better.. but…

“But we want to give our users a subdomain each, I don’t want to be limited!”

Fair enough, but LetsEncrypt will remove the account limitations if you ask them.

“But then all these domains show up in the LE registry.”

If you’re hoping that people wont find your domain and that’s your only measure of security then you’re a little beyond hope.

In my opinion if you’re lazy enough to warrant a wildcard cert then you’re too lazy to do security properly anyway, period.

If you go wildcard you’ve got to fix this for yourself:
Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
Management: If the wildcard certificate needs to be revoked, all sub-domains using it will need a new certificate.
and you’re removing:
Protection (Ex: VeriSign Wildcard SSL Certificates are not insured.)


The reason I bring this up is because on every topic about LetsEncrypt I see someone complaining that LetsEncrypt do not fit their use-case because: “they do not support wildcard certs” and “[we] will not use [them] until they do”

Personally, I see it as a good thing they don’t support wildcard certificates as it’s promoting better behaviour. Remember, you’re allowed to have as many certificates as you want, if you hit a rate limit they will change it on your account but by default you can have 20 new certificates a week for a total of 1,040 new domains a year. Which is enough for most companies I think.

There’s even an RFC decrying the use of wildcard certs.

So please, stop asking for it, there are much better and cleaner ways to architect your application.

 
21
Kudos
 
21
Kudos

Now read this

Failing to monitor, dying without dignity.

Today, I’m going to tell you about the story of an obscure kernel bug, how we missed it, and how we’re still recovering from the effect I should preface this by saying that, generally, I like virtual machines. I have 5 actual servers... Continue →