Follow Up: Wildcard TLS Certificates
I wrote an article some time ago in a fit of anger about people continually bashing LetsEncrypt for not supporting wildcard certificates.
Why was I angry? Well my original post is here and it’s about as ranty as
you would expect from me. In it, I call people lazy and falsely attribute the
fact that SSL Certificate Authorities will not insure their wildcard certificates as a reason to avoid them. (I implied customer insurance would inform business decision making).
I figured since LetsEncrypt have caved and started supporting wildcard certs I should follow up and touch base more objectively with the reasons I feel it’s a poor practice for your users. There are reasons to use wildcard SSL certs and I’ll touch on those too.
Revocation Issue #
Revocation is, unfortunately, in 2017, not a solved problem.
OCSP is still susceptible to this attack since 2009.
Revocation is amplified on wildcard externally signed CA certificates because people often ‘copy’ the cert to other services in order to have valid externally signed TLS access. (shared mail/http etc). This should be less of a problem with LE since they only allow 3 month validity on their signed certificates.
Verify any sub-domain #
I gave an example the last time of a situation at my previous employment. I have another example too now and I’ll tell both:
$job[-2]; checkout #
My previous company uses an EV cert required for PCI compliance on its checkout. Only its checkout. Back in the day this used to limit the scope of PCI and additionally lower server CPU footprint for non-checkout activities.
For this we used a separate domain: checkout.company.com
All is well and good in PCI land, until one day I noticed someone on the checkout page with no “green bar”
What had happened?
Someone had requested *.company.com and enabled it on the load balancers.
This meant a chunk of code that checked your current protocol never triggered and ‘checkout’ servers (which checked how people requested them) were unaware that it was the wrong cert.
Nobody noticed, but those transactions could have caused serious harm had somebody investigated from the bank.
Not to mention, the public key for the wildcard cert was not stored correctly.
$job[-1]; The ubiquitous wildcard #
My current employment also has payment systems in place. It is, however, a very large enterprise and it’s silo-ed in just the way you would expect.
Sysadmins who have access to an e-commerce back-end do not have access to AD.
However, I recently came upon a monitoring installation which had been signed with the apparently easily available: *.company.com… Which I found was:
- “Securing” mail servers.
- “Securing” checkouts and web-servers
- “Securing” game back-ends
- “Securing” APIs
- “Securing” Authentication services
- “Securing” external LDAP authentication
- “Securing” our corporate VPN.
With access to the private key, I could impersonate any of these (and, I did to
prove a point to a colleague).
My point is this: wildcard certificates automatically vouch for any and all host
names within their domain. This can be convenient for administrators but also poses the risk of vouching for rogue or misconfigured/insecure hosts.
My examples of poor wildcard handling above are using the most conventional wildcard definitions.. There are of course www.*.company.com, *.co.uk, thing.*.com which would be considered valid. More information can be found in this RFC for Service Identity which identifies these shortcomings.
I wrote a false conversation before and I feel like I should do something
similar here:
“We use it on a separate namespace, so your argument is invalid.”
You still have the problem of one service impersonating another.
“We have too many sub-domains!”
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 sub-domain each, I don’t want to be limited!”
That’s fair, then use a namespace or, even better, get your limits raised by LE.
They seem fairly open about increasing limits if you hit their API limitations.
“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.
Conclusion #
Look, I’m not saying it’s easy to take security seriously, wildcard certificates
might be intensely convenient, but I wholeheartedly disagree with their usage for pure convenience. In my mind we should consider the fact that TLS certs are “P2P”/“E2E”. It’s unthinkable to share signal keys between devices, but somehow it’s OK for businesses to just throw around a pair of keys to secure everything.
I only ask that, the next time you make a service, you don’t assume a wildcard cert will be protecting all sub-domains. Use *.users.company.com to segment the namespace if you’re absolutely going to; or ask LE to lift the restrictions.