I applaud LetsEncrypt for disclosing rapidly and thoroughly. During the period after the initial announcement and before the full report, I quickly read the ACME spec portion pertaining to TLS-SNI-01.
I had not previously read the details of that validation method as that method was not once I intended to utilize. Upon reading, I was surprised that the mechanism had survived scrutiny to make it through to industry adoption and production use. There exists an unambiguous comparative deficiency between the TLS-SNI-01 validation mechanism and every other validation mechanism presently utilized by LetsEncrypt: Specifically, the portion of the protocol which validates connection to the infrastructure that responds for a given domain label presents the entire value of the correct "answer" to the challenge within the question itself (the TLS SNI name indication toward the server that the DNS says the domain-label being tested is at.) The result of this is that we can definitively assert that the TLS-SNI-01 protocol provides no evidence that the party who requested the validation (and would receive the certificate) is the party responsible for the answer which arises from the infrastructure that the DNS says is the right infrastructure for a given domain label. Furthermore, it would not be shocking that a plausible design for a load balancer or hosting infrastructure might on-demand generate a self-signed or corporate CA signed certificate for a heretofore unknown to the infrastructure domain label as surfaced in the TLS SNI name value. That would "just work" in terms of validating any TLS-SNI-01 challenge on behalf of any outside party who happens to know that a given domain label is directed in the DNS to infrastructure of that behavioral mode. LetsEncrypt has been such a shining beacon of good practice in this space that I feel that many -- certainly it is my own opinion -- view LetsEncrypt as a "best practices" model CA for domain validation. The continuance of the TLS-SNI-01 validation method, to my mind, would be a marked departure from that position. I believe LetsEncrypt should give careful consideration to the reputational risks involved. Now that the mode of the problem with this method is in the public mind, there will be detractors looking to achieve a publishable mis-issuance. LetsEncrypt's proposed plan to work with hosting service providers on the Internet seems naive in that light. Participants in that market come and go all the time. If the plan for returning TLS-SNI-01 to sufficient integrity for reliance by the WebPKI requires affirmative effort on the part of an uncountable number of current and future participants in the hosting space... I do not mean to be rude, but are you saying this with a straight face? Just my thoughts... Matt Hardeman On Wed, Jan 10, 2018 at 3:33 AM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
