Hacker News Reader

Hi,

The attack described in the blog post dates from 2015. The ACME challenge protocol has been updated a few times since then. You are completely correct that signatures aren't really needed for the challenges, yet this was the initial design and it is a property of the signatures that leads to the described attack.

The trick of Andrew Ayer's attack is that the various challenges were just a particular signature under the account's public key, with the assumption that the signature uniquely identifies the public key (of the Let's Encrypt account) which controls the website. Unfortunately, this isn't true.

If you make a signature for some message and your public key. I can pick my own public key such that your signature verifies under my public key. This is maybe a little counter intuitive.

So when someone uploaded their challenge, an attacker could make a new public key and claim "hey, that challenge works under my public key!" and Let's Encrypt would then issue them with a certificate. Deleting the challenge after use would partially help, but in practice DNS is pretty slow to update and HTTP challenges might also be cached.

Disclosure: I'm an author on the paper linked in the latter half of the blog post.

Keep in mind the vulnerability was in a 5 year old version of the protocol and has since been fixed, so the description of the protocol won't match what you're familiar with.

> In the attack by Eve, it is claimed that Eve recovers the account

The article says Eve "recover[s] the example.com domain". It should say request a certificate for example.com. I've mentioned this to the author.

> But this file is usually automatically deleted after the certificate renewal is completed.

Usually, but not always, and an attacker could always try to race the legitimate certificate request.

> It's not even clear from the explanation what Eve could do with this file.

Eve takes the signature and constructs her own ACME account key that produces the same signature as Alice's account key. Note though that the HTTP challenge wasn't practically exploitable because Eve would get a different token which wouldn't exist on Alice's server. The attack is better explained in terms of the DNS challenge, which was practically exploitable. You can find such explanations in my blog post (https://www.agwa.name/blog/post/duplicate_signature_key_sele...) or IETF post (https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJC...).

> The whole security of the ACME protocol relies on the assumption that nobody except the owner of the domain name can return a special crafted data when `http://<domain>/.well-know/acme-challenge/<token>` is requested with the GET method. Cryptographic signatures aren't really needed here.

Exactly right! It's the point I made here: https://news.ycombinator.com/item?id=22524805 Fortunately, ACME stopped using signatures in challenges after I found this vulnerability.

Cryptographically it seems as though all we need in HTTP is that we get back a special token when we ask for it. But it's essential in designing real-world security systems to understand real world practice. Historically (prior to the Ten Blessed Methods explicitly forbidding this) it was not uncommon for HTTP-based DV to go like this:

Customer: I want a cert for www.example.com

Average CA: OK, put this file (containing the text 12345678) on http://www.example.com/average-12345678

Customer: OK done.

Average CA does GET http://www.example.com/average-12345678 verifies that the token 12345678 is present and issues certificate

Cryptographically it's fine, who else but the owner could make this test pass? But in the real world lots of web servers when you ask them for average-12345678 will go "Sorry, average-12345678 isn't available. Maybe you'd like to visit our home page?" and that text matches the token and passes the test.

That really happened, to real commercial CAs which are still trusted today, because they hadn't thought about real world problems (also in one case because they goofed an HTTP response code check so if you gave that reply as a 404 their code wouldn't notice it was a 404 before passing the test)

Let's Encrypt was designed to prevent this mistake (even though embarrassingly it was still happening at other CAs years later until the Ten Blessed Methods were de facto imposed by Mozilla policy) but managed to make a very similar mistake in tls-sni-01 which was dangerous because Apache httpd (and maybe nginx?) has crazy default behaviour for virtual hosts on HTTPS. Again, in principle tls-sni-01 looks safe, who else but the real owner could answer TLS setups with bogus SNI information? But the real world gives us an answer: Anybody sharing a cheap bulk hosting site with you if the host used one of the world's most popular web servers.

You can see analogues in the real world too. We had a sub-thread on HN recently about RFID entry badges. Most use a very passive design which is easily cloned. But you can buy hard-to-clone secure systems for this role. Having done so you might assume only employees and legitimate visitors can get into your facility. And then you see that in the real world your employees are still letting people tailgate and leaving fire doors open to take a smoke break and you realise that cryptographic security of the RFID entry cards was not in fact your big problem in controlling which people are in the building.

It’s not assuming MITM or that the attacker can upload the signature to the site.

The attack is that the attacker can reuse the already uploaded signature in a way that allows them to get certificates issued under their account instead of the initial owner.

This blog is a little confusing about that since it does read like they are supposed to upload their own sig with the graphic used.

This post and linked IETF report is a little more clear: https://www.agwa.name/blog/2015/12

BTW this is not yet in the book, so if you have any suggestion to make the explanation or the diagrams clearer I will take them :)