Before issuing a certificate, Let’s Encrypt needs to verify domain ownership in some way. The practically workable methods as of 2015 all involve relying on cryptographically insecure methods. This is because there is no cryptographically secure way to verify domain ownership supported by the IANA and their delegates who control domain registration (to my knowledge).
The ACME protocol RFC has a section which discusses how to minimize the risks of attacks during this bootstrapping phase. For example, it discusses a method which I consider to be the most practically useful called “Querying the DNS from multiple vantage points to address local attackers”.
I would like to discuss this method and have the following questions:
Are Let’s Encrypt planning to perform these checks from multiple vantage points?
Will the checks be limited to DNS lookups or will the HTTP aspects of the verification also be undertaken from multiple vantage points?
Are customer nodes running the daemon going to participate in this distributed checking (like Convergence)?
Will the results of these distributed checks be published publicly to a database (like Certificate Transparency)?
I mean at least the attack in general. About the DNS method here my opinion: If you access the records from various points this can of course increase the change that everything is correct there, but it's still problematic that it's just not signed. (Except you're using DNSSEC)
Along with the challenges, the Let’s Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair.
Hi @rugk Thanks for your response. I understand that cryptographic methods are used whenever possible as part of the ACME protocol. In my original questions, though, I’m actually asking about where this isn’t possible. The Simple HTTP method will be used a lot because it is often the easiest option.
There is a known attack against the Simple HTTP method discussed in the RFC for the ACME protocol: an attacker who controls the unverified DNS and TCP connections made by the Let’s Encrypt servers can get it to issue a certificate for any domain. This isn’t a new attack because all CAs are, at least in theory, vulnerable to it. What is new is that this is a CA that is free and designed for automation. I think this makes opportunistic attacks possible for the first time.
An opportunistic attack might be one where you decide to hijack as many domains as possible from as many vantage points as possible and apply data mining techniques to pull out potentially exploitable information. The average return from hacking a single domain might only be on the order of just cents so buying a certificate from an existing CA for $5 wouldn’t be profitable. Getting one from Let’s Encrypt might cost less than a cent making this possible for the first time.
There are ways to mitigate against this kind of attack. What do existing CAs do and what are Let’s Encrypt planning to do?
Hey! There has also been some previous discussion of this in the thread linked below. Part of the original design of Boulder (the Let's Encrypt backend service) was to use multiple Validation Authorities (the servers that preform challenge validation) that must agree about the status of a challenges outcome. The design work for this is still ongoing as it presents a somewhat complex engineering problem within the current implementation.