On Wednesday, January 10, 2018 at 1:33:31 AM UTC-8, [email protected] wrote: > At approximately 5 p.m. Pacific time on January 9, 2018, we received a 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. We quickly > confirmed the issue and mitigated it by entirely disabling TLS-SNI-01 > validation in Let’s Encrypt. We’re grateful to Frans for finding this issue > and reporting it to us. > > We’d like to describe the issue and our plans for possibly re-enabling > TLS-SNI-01 support. > > Problem Summary > > In the ACME protocol’s 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-signed > certificate with a specific, invalid hostname (for example, > 773c7d.13445a.acme.invalid), and configures the web server on the domain name > being validated to serve that certificate. The ACME server then looks up the > domain name’s IP address, initiates a TLS connection, and sends the specific > .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 certificates 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 without > proving domain control. > > When both are true of a hosting provider, an attack is possible. Suppose > example.com’s 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 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.com, and be willing to issue a > certificate for example.com even though the attacker doesn’t 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 > provider itself acts as an ACME client. > > Our Plans > > Shortly after the issue was reported, we disabled TLS-SNI-01 in Let’s > Encrypt. However, a large number of people and organizations 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. > > 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 > affected, 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 > completed, is to re-enable the TLS-SNI-01 challenge type with vulnerable > providers blocked from using it. > > We’re 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’re looking 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 response is applaudable. However, it doesn't mention anything about whether anyone has exploited this already. Have you started analyzing your existing certs to see if any may have been mis-issued? If so, how? Thanks, Santhan _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
