On Tuesday, January 9, Detectify’s security advisor Frans Rosén discovered and reported a security issue in in TLS-SNI-01 validation in Let’s Encrypt. Exploiting the issue could allow an attacker to issue certificates for any domain, regardless of whether they own the domain or not. Following Frans’ report, Let’s Encrypt disabled TLS-SNI-01 validation and recommends using HTTP-01 or DNS-01 validation methods instead.
If you’d like to read Frans Rosén’s technical write-up, head over to our Labs blog.
What can happen?
You have probably come across the green lock together with the word “Secure” in the top left corner of your browser. The lock is displayed when you are browsing securely, using the SSL/TLS protocol that prevents hackers from intercepting your data.
An SSL/TLS certificate encrypts the information sent over your connection and authenticates the identity of the certificate’s holder. This means that websites with a certificate are often considered reliable and more secure than websites without a certificate, served over http. Certificates are issued by Certificate authorities (CAs) like Let’s Encrypt.
However, if an attacker were to exploit the TLS-SNI-01 validation, they could issue a certificate for any website. As the site would seemingly be protected with an SSL/TLS certificate, its visitors would consider it secure while the attacker could intercept traffic and sensitive information.
How the TLS-SNI-01 challenge works
When issuing certificates, Let’s Encrypt uses ACME’s TLS-SNI-01 challenge to validate the domain. First, the ACME server generates a random token and sends it to the client. The client then uses the token to create a self-signed certificate with a hostname that looks like xyz.abc.acme.invalid. The cloud provider checks that domain’s IP address and, if the self-signed certificate matches the hostname, a Let’s Encrypt certificate is issued.
Why is this an issue?
In short, TLS-SNI-01 validation can be exploited when domain ownership is not validated and multiple users are hosted on the same IP address. At the time of Frans’ report to Let’s Encrypt, this is was the case with a large number of major cloud providers. AWS CloudFront and Heroku quickly implemented the patch and no longer allow customers to add domains that end with .invalid.
- Domain ownership is not validated
Many major cloud providers do not validate domain ownership, but instead simply allow you to add any domain to them. This makes it possible for an attacker to try find orphaned domains still pointing to the service and claim them without actually owning any of the domains. In this case, it also meant that you could add xyz.abc.acme.invalid and upload a self-signed certificate, and that would then work according to the validation method.
- Multiple users are hosted on the same IP address
TLS-SNI-01 validation is vulnerable when cloud providers offering shared hosting services host many users on the same IP address, in combination with not having a proper domain validation.
What happens now?
Let’s Encrypt acted quickly and disabled TLS-SNI-01 validation. Since then, TLS-SNI-01 validation has only been re-enabled for large providers that are not vulnerable to the exploit. For new accounts, TLS-SNI-01 remains disabled by default. Despite re-enabling the validation method for major providers, Let’s Encrypt recommend users to switch to HTTPS or DNS validation. On Friday the 12th, Let’s Encrypt announced that they will sunset both TLS-SNI-01 and TLS-SNI-02 completely. They will discuss this further with the IETF ACME working group to make sure a proper specification takes this issue into account.
Additional reading
Frans Rosén’s write-up on Detectify Labs
Let’s Encrypt’s incident summary (2018-01-09)
Let’s Encrypt’s update (2018-01-11)