Certificate authority Let's Encrypt has disabled TLS-SNI-01 validation on its service. Through the vulnerability, a hacker could have requested certificates for domains that were not theirs.
TLS certificates are used to set up an encrypted connection between websites and visitors. Let's Encrypt, which issues free TLS certificates, has several ways to check whether the applicant for a certificate is also the owner of the corresponding domain. One of these methods is the "ACME TLS-SNI-01" validation, where communication between the server of the specified domain and the server of Let's Encrypt takes place. In this way, Let's Encrypt validates that it is a legitimate application.
According to a posting by Let's Encrypt, it had report from Frans Rosén of Detectify outlining a method of exploiting some shared hosting infrastructures to obtain certificates for domains he did not control, by making use of the ACME TLS-SNI-01 challenge type.
Rosén noticed that at least two large hosting providers combine two properties that together violate the assumptions behind TLS-SNI. First, many users are hosted on the same IP address, and, second, users have the ability to upload certificates for arbitrary names without proving domain control. The organisations said that when both are true of a hosting provider, an attack is possible.
As an example, its said that if a target domain's (example.com in this instance) DNS is pointed at the same shared hosting IP address as a site controlled by the attacker. The attacker can run an ACME client to get a TLS-SNI-01 challenge, then install their .acme.invalid certificate on the hosting provider. When the ACME server looks up example.com157, it will connect to the hosting provider's IP address and use SNI to request the .acme.invalid hostname.
“The hosting provider will serve the certificate uploaded by the attacker. The ACME server will then consider the attacker's ACME client authorized to issue certificates for example.com157, and be willing to issue a certificate for example.com157 even though the attacker doesn't actually control it,” said the organisation.
“This issue only affects domain names that use hosting providers with the above combination of properties. It is independent of whether the hosting provider itself acts as an ACME client. It applies equally to TLS-SNI-02.”
It added that after the issue was reported, it disabled TLS-SNI-01 in Let's Encrypt. However, a large number of people and organisations use the TLS-SNI-01 challenge type to get certificates.
“It's important that we restore service if possible, though we will only do so if we're confident that the TLS-SNI-01 challenge type is sufficiently secure,” said Let's Encrypt.
It added that it believed the issue can be addressed by having certain services providers implement stronger controls for domains hosted on their infrastructure. “We have been in touch with the providers we know to be affected, and mitigations will start being deployed for their systems shortly,” it said.
In an update, Let's Encrypt said that it has decided to re-enable the TLS-SNI-01 challenge for certain major providers who are known not to have issues while it investigates re-enabling TLS-SNI-01 in general.
Hari Nair, director of cryptographic research at Venafi, told SC Media UK that this is really about weak security practices by some hosting providers.
“Let's Encrypt has mitigated the damage to a certain extent, but ultimately, how effective those steps will be depends on how well hosting providers implement certificate security on their end,” he said.
He added that it's possible that there could be a spate of revocations in response to this event.
“The reality is that detection of mis-issued certificates is extremely hard and checking for revocation status is not something that the industry has traditionally done well, so it's not clear how much impact revocations will have,” said Nair.
“Google's move to require Certificate Transparency for all certificates, including DV certs, will help surface these kind of issues sooner, but that move is currently slated for April 2018. In the meantime, the only thing organisations can do to protect themselves is to stay vigilant in their efforts to monitor for mis-issued or maliciously issued certificates. The problem is that the vast majority of organisation don't have the technology they need to do this.”