Let’s Encrypt validation exploit detected, no hosted domains affected on our platform
A problem with the Let’s Encrypt Certificate Authority’s ACME protocol was detected on January 9, 2018.
It turned out that by exploiting a vulnerability in the ACME TLS-SNI-01 challenge type, malicious users could obtain SSL certificates for domains they did not control.
Let’s Encrypt acted immediately and disabled TLS-SNI-01 support.
What is the TLS-SNI-01 vulnerability about?
The vulnerability was reported by a Detectify security professional who had discovered that the ACME protocol’s TLS-SNI-01 verification challenge procedure could be exploited.
He alerted the Let’s Encrypt CA about a method of exploiting certain shared hosting infrastructures to obtain certificates for domains he did not own.
The attack method was quickly confirmed by Let’s Encrypt and a flaw in the abovementioned TLS-SNI-01 challenge procedure was cited as the cause of the issue.
In order for a Let’s Encrypt SSL to be issued, the TLS-SNI-01 challenge in question must be satisfied.
To understand the mechanism of the domain validation procedure itself, one needs to know how it works in the backend:
First, the Certificate Authority (CA) generates a random token and communicates it to the hosting server-installed ACME client.
The latter uses the token to create a self-signed certificate with a given invalid hostname.
The Certificate Authority then looks up the domain name’s IP, initializes a TLS connection and sends the invalid hostname to the SNI extension.
If the response is a self-signed certificate, which contains the hostname, the domain name is considered validated and the ACME client is permitted to issue certificates for it.
As it has turned out, a couple of large hosting providers combine two conditions that together open the door to TLS-SNI-01 procedure violations:
- Many users are hosted on the same IP address;
- Users are able to upload certificates for arbitrary names without proving domain ownership;
If both conditions are present, the TLS-SNI-01 procedure can potentially be exploited.
When the issue was reported, Let’s Encrypt rapidly disabled TLS-SNI-01 validation.
However, this is just a temporary solution. As it is, a permanent one has to be found.
In the meantime, Let’s Encrypt recommended that hosting providers implement the alternative HTTP-01 or DNS-01 challenges as a long-term solution instead, if they haven’t already done so.
Are my domains affected by the TLS-SNI-01 vulnerability?
Luckily, we use namely the recommended HTTP-01 and DNS-01 challenges for domain validation and certificate issuance purposes.
This is why, the domain names that are hosted on our platform are not prone to TLS-SNI-01 challenge procedure violations.
NOTE: However, if you manage domains that are registered through us, but are not hosted on our platform, we’d recommend you to get in touch with the hosting provider whose services you are using and make sure that they’ve taken measures to secure their Let’s Encrypt certificates.
Originally published Tuesday, January 16th, 2018 at 1:13 pm, updated January 17, 2018 and is filed under SSL Certificates.Tags: SSL certificate