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.
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 host name.
The Certificate Authority then looks up the domain name’s IP, initializes a TLS connection and sends the invalid host name 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.