3 ms·

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

by agwa 7y ago

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_selection_attack_in_lets_encrypt https://www.agwa.name/blog/post/duplicate_signature_key_sele...) or IETF post (https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc/ 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>` 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 https://news.ycombinator.com/item?id=22524805 Fortunately, ACME stopped using signatures in challenges after I found this vulnerability.

tialaramex 7y ago
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 http://www.example.com/average-12345678 Customer: OK done. Average CA does GET http://www.example.com/average-12345678 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.

by agwa 7y ago

tialaramex 7y ago

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 http://www.example.com/average-12345678 Customer: OK done. Average CA does GET http://www.example.com/average-12345678 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.