A exploit 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 for their SSL Certificates.
What is the Let’s Encrypt TLS-SNI-01 Vulnerability? How Does It Affect Me?
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 procedure of the domain validation process itself for let’s encrypt, 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 (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 hosting server is permitted to issue certificates for it.
As it has turned out, several 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 at DDNS?
Luckily, we use the recommended HTTP-01 and DNS-01 challenges for domain validation and certificate issuance purposes for issuing Let’s Encrypt SSL certificates.
This is why, any domain names that are hosted on our platform are not prone to any TLS-SNI-01 challenge procedure violations.
IMPORTANT NOTE: If you manage domains that are registered through us, but are not hosted on our cloud platform, we do recommend you to get in touch with your current hosting provider whose services you are using and make sure that they’ve taken measures to secure their Let’s Encrypt certificates!!
Here’s to another safe and reliable year of providing hosting services to our customers in 2018 at DDNS Cloud Hosting & Domain Names!
DDNS Cloud Hosting & Domain Names!