2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

At approximately 5 p.m. Pacific time on January 9, 2018, we received a repo=
rt from Frans Ros=C3=A9n of Detectify outlining a method of exploiting some=
 shared hosting infrastructures to obtain certificates for domains he did n=
ot control, by making use of the ACME TLS-SNI-01 challenge type. We quickly=
 confirmed the issue and mitigated it by entirely disabling TLS-SNI-01 vali=
dation in Let=E2=80=99s Encrypt. We=E2=80=99re grateful to Frans for findin=
g this issue and reporting it to us.

We=E2=80=99d like to describe the issue and our plans for possibly re-enabl=
ing TLS-SNI-01 support.

Problem Summary

In the ACME protocol=E2=80=99s TLS-SNI-01 challenge, the ACME server (the C=
A) validates a domain name by generating a random token and communicating i=
t to the ACME client. The ACME client uses that token to create a self-sign=
ed certificate with a specific, invalid hostname (for example, 773c7d.13445=
a.acme.invalid), and configures the web server on the domain name being val=
idated to serve that certificate. The ACME server then looks up the domain =
name=E2=80=99s IP address, initiates a TLS connection, and sends the specif=
ic .acme.invalid hostname in the SNI extension. If the response is a self-s=
igned certificate containing that hostname, the ACME client is considered t=
o be in control of the domain name, and will be allowed to issue certificat=
es for it.

However, Frans noticed that at least two large hosting providers combine tw=
o 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 without=
 proving domain control.

When both are true of a hosting provider, an attack is possible. Suppose ex=
ample.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 to =
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 c=
onnect to the hosting provider=E2=80=99s 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=
=E2=80=99s ACME client authorized to issue certificates for example.com, an=
d be willing to issue a certificate for example.com even though the attacke=
r doesn=E2=80=99t actually control it.

This issue only affects domain names that use hosting providers with the ab=
ove combination of properties. It is independent of whether the hosting pro=
vider 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 certain =
services providers implement stronger controls for domains hosted on their =
infrastructure. We have been in touch with the providers we know to be affe=
cted, and mitigations will start being deployed for their systems shortly.

Over the next 48 hours we will be building a list of vulnerable providers a=
nd their associated IP addresses. Our tentative plan, once the list is comp=
leted, is to re-enable the TLS-SNI-01 challenge type with vulnerable provid=
ers blocked from using it.

We=E2=80=99re also going to be soliciting feedback on our plans from our co=
mmunity, partners and other PKI stakeholders prior to re-enabling the TLS-S=
NI-01 challenge. There is a lot to consider here and we=E2=80=99re looking =
forward to feedback.

We will post more information and details as our plans progress.
0
josh
1/10/2018 9:33:20 AM
mozilla.dev.security.policy 1337 articles. 2 followers. Post Follow

1 Replies
62 Views

Similar Articles

[PageSpeed] 16

On Wednesday, January 10, 2018 at 1:33:31 AM UTC-8, jo...@letsencrypt.org w=
rote:
> 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.
>=20
> We=E2=80=99d like to describe the issue and our plans for possibly re-ena=
bling TLS-SNI-01 support.
>=20
> Problem Summary
>=20
> 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.
>=20
> However, Frans noticed that at least two large hosting providers combine =
two properties that together violate the assumptions behind TLS-SNI:
>=20
> * 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.
>=20
> 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.
>=20
> 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.
>=20
> Our Plans
>=20
> 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.
>=20
> 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=
..
>=20
> 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.
>=20
> 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.
>=20
> 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?

Thanks,
Santhan
0
Santhan
1/10/2018 8:40:00 PM
Reply: