Let's Encrypt – a SSL/TLS certificate authority run by the non-profit Internet Security Research Group (ISRG) to programmatically provide websites with free certs for their HTTPS websites – on Thursday said it is discontinuing TLS-SNI validation because it's insecure in the context of many shared hosting providers.
TLS-SNI is one of three ways Let's Encrypt's Automatic Certificate Management Environment (ACME) protocol validates requests for TLS certificates, which enable secure connections when browsing the web, along with the confidence-inspiring display of a lock icon. The other two validation methods, HTTP-01 and DNS-01, are not implicated in this issue.
The problem is that TLS-SNI-01 and its planned successor TLS-SNI-02 can be abused under specific circumstances to allow an attacker to obtain HTTPS certificates for websites that he or she does not own.
Such a person could, for example, find an orphaned domain name pointed at a hosting service, and use the domain – with an unauthorized certificate to make fake pages appear more credible – without actually owning the domain.
For example, a company might have investors.techcorp.com set up and pointed at a cloud-based web host to serve content, but not investor.techcorp.com. An attacker could potentially create an account on said cloud provider, and add a HTTPS server for investor.techcorp.com to that account, allowing the miscreant to masquerade as that business – and with a Let's Encrypt HTTPS cert, too, via TLS-SNI-01, to make it look totally legit.
It sounds bonkers but we're told some cloud providers allow this to happen. And that's why Let's Encrypt ditched its TLS-SNI-01 validation processor.
It turns out that many hosting providers do not validate domain ownership. When such providers also host multiple users on the same IP address, as happens on AWS CloudFront and on Heroku, it becomes possible to obtain a Let's Encrypt certificate for someone else's website via the TLS-SNI-01 mechanism.
On Tuesday, Frans Rosén, a security researcher for Detectify, identified and reported the issue to Let's Encrypt, and the organization suspended certificate issuance using TLS-SNI-01 validation, pending resolution of the problem.
In his account of his proof-of-concept exploit, Rosén recommended three mitigations: disabling TLS-SNI-01; blacklisting
.acme.invalid in certificate challenges, which is required to get a cert via TLS-SNI-01; and looking to other forms of validation because TLS-SNI-01 and 02 are broken given current cloud infrastructure practices.
AWS CloudFront and Heroku have since tweaked their operations based on Rosén's recommendation, but the problem extends to other hosting providers that serve multiple users from a single IP address without domain ownership validation.
Late Thursday, after temporarily reenabling the validation method for certain large hosting providers that aren't vulnerable, Let's Encrypt decided it would permanently disable TLS-SNI-01 and TLS-SNI-02 for new accounts.
Those who previously validated using TLS-SNI-01 will be allowed to renew using the same mechanism for a limited time.
"We have arrived at the conclusion that we cannot generally re-enable TLS-SNI validation," said ISRG executive director Josh Aas in a forum post. "There are simply too many vulnerable shared hosting and infrastructure services that violate the assumptions behind TLS-SNI validation."
Aas stressed that Let's Encrypt will discontinue using the TLS-SNI-01 and TLS-SNI-02 validation methods. ®