Let’s Encrypt – the much loved SSL/TLS cert free cert people run by the not for profit Internet Security Research Group (ISRG) – let us know on Thursday that it’s stopping offering TLS-SNI validation. Why? Well, because it’s totally insecure on lots of shared hosting providers. That’s why. Sigh.
The snappily named TLS-SNI is just one of three ways the Let’s Encrypt protocol checks requests for TLS certs. TLS certificates enables secure web browsing. It’s when you see the Grandma-pleasing padlock on a shopping site, for example. The other two methods (HTTP-01 and DNS-01) are not vulnerable or at risk.
So, what’s the problem exactly?
Well, under certain circumstances, TLS-SNI-01 can be abused to let an attacker look like they have HTTPS certificates for a domain he or she doesn’t actually own. Hmm. Not so good then.
A naughty person, could, for example, search for an orphaned domain that’s still set up to point at a hosting service and use that domain, with a fake SSL certificate, to make their fake, scammy phishing pages look legit. And they wouldn’t even have to own the domain.
For example, a company could have news.foobar.com sitting on a shared cloud hosting set up. Aforementioned naughty person could set up new.foobar.com on the same shared host. Then just add in an HTTPS cert from Let’s Encrypt which would let them pretend they were that business. And it would look totally legitimate – padlock and all.
I know, it sounds unbelievable a host would allow this to happen, but many do. Including our friends at AWS and Heroku.
Security researcher to the rescue (again)
The super clever Frans Rosén, a security researcher for Detectify found the problem and quite rightly reported to Let’s Encrypt. To be fair to them, Let’s Encrypt stopped the flaw in two hours. AWS CloudFront and Heroku have fiddled around with things based on Rosén’s advice, but other hosts that have multiple users on the same IP without checking for domain ownership validation.
Let’s Encrypt suspended the cert, and then re enabled it for large hosts who aren’t vulnerable, then thought they’d just chuck the whole thing in the bin for any new accounts. Better to be safe than sorry.
ISRG executive director Josh Aas said:
“We have arrived at the conclusion that we cannot generally re-enable TLS-SNI validation…There are simply too many vulnerable shared hosting and infrastructure services that violate the assumptions behind TLS-SNI validation.”