On Wednesday, January 10, 2018 at 1:33:31 AM UTC-8, jo...@letsencrypt.org w=
> At approximately 5 p.m. Pacific time on January 9, 2018, we received a re=
port from Frans Ros=C3=A9n of Detectify outlining a method of exploiting so=
me shared hosting infrastructures to obtain certificates for domains he did=
not control, by making use of the ACME TLS-SNI-01 challenge type. We quick=
ly confirmed the issue and mitigated it by entirely disabling TLS-SNI-01 va=
lidation in Let=E2=80=99s Encrypt. We=E2=80=99re grateful to Frans for find=
ing this issue and reporting it to us.
> We=E2=80=99d like to describe the issue and our plans for possibly re-ena=
bling TLS-SNI-01 support.
> Problem Summary
> In the ACME protocol=E2=80=99s TLS-SNI-01 challenge, the ACME server (the=
CA) validates a domain name by generating a random token and communicating=
it to the ACME client. The ACME client uses that token to create a self-si=
gned certificate with a specific, invalid hostname (for example, 773c7d.134=
45a.acme.invalid), and configures the web server on the domain name being v=
alidated to serve that certificate. The ACME server then looks up the domai=
n name=E2=80=99s IP address, initiates a TLS connection, and sends the spec=
ific .acme.invalid hostname in the SNI extension. If the response is a self=
-signed certificate containing that hostname, the ACME client is considered=
to be in control of the domain name, and will be allowed to issue certific=
ates for it.
> However, Frans noticed that at least two large hosting providers combine =
two properties that together violate the assumptions behind TLS-SNI:
> * Many users are hosted on the same IP address, and
> * Users have the ability to upload certificates for arbitrary names witho=
ut proving domain control.
> When both are true of a hosting provider, an attack is possible. Suppose =
example.com=E2=80=99s DNS is pointed at the same shared hosting IP address =
as a site controlled by the attacker. The attacker can run an ACME client t=
o get a TLS-SNI-01 challenge, then install their .acme.invalid certificate =
on the hosting provider. When the ACME server looks up example.com, it will=
connect to the hosting provider=E2=80=99s IP address and use SNI to reques=
t the .acme.invalid hostname. The hosting provider will serve the certifica=
te uploaded by the attacker. The ACME server will then consider the attacke=
r=E2=80=99s ACME client authorized to issue certificates for example.com, a=
nd be willing to issue a certificate for example.com even though the attack=
er doesn=E2=80=99t actually control it.
> This issue only affects domain names that use hosting providers with the =
above combination of properties. It is independent of whether the hosting p=
rovider itself acts as an ACME client.
> Our Plans
> Shortly after the issue was reported, we disabled TLS-SNI-01 in Let=E2=80=
=99s Encrypt. However, a large number of people and organizations use the T=
LS-SNI-01 challenge type to get certificates. It=E2=80=99s important that w=
e restore service if possible, though we will only do so if we=E2=80=99re c=
onfident that the TLS-SNI-01 challenge type is sufficiently secure.
> At this time, we believe that the issue can be addressed by having certai=
n services providers implement stronger controls for domains hosted on thei=
r infrastructure. We have been in touch with the providers we know to be af=
fected, and mitigations will start being deployed for their systems shortly=
> Over the next 48 hours we will be building a list of vulnerable providers=
and their associated IP addresses. Our tentative plan, once the list is co=
mpleted, is to re-enable the TLS-SNI-01 challenge type with vulnerable prov=
iders blocked from using it.
> We=E2=80=99re also going to be soliciting feedback on our plans from our =
community, partners and other PKI stakeholders prior to re-enabling the TLS=
-SNI-01 challenge. There is a lot to consider here and we=E2=80=99re lookin=
g forward to feedback.
> We will post more information and details as our plans progress.
As others have mentioned, the transparency in the disclosure and quick resp=
onse is applaudable. However, it doesn't mention anything about whether any=
one has exploited this already. Have you started analyzing your existing ce=
rts to see if any may have been mis-issued? If so, how?