Hey Mateusz, Thanks a lot for suggesting this. This sounds like a great idea to me. Please feel free to file an issue on the Github spec -- or send a pull request!
The only exception that occurs to me is the recoveryToken / recoveryContact challenge types. The recoveryToken challenge is done in-band to ACME, so it's already signed with the account key pair. For recoveryChallenge, I guess you could bind in the key pair, but given that it's intended to be more human-facing, that seems counterproductive. --Richard On Sun, Jan 25, 2015 at 3:59 AM, Mateusz Jończyk <[email protected]> wrote: > Hello, > Suppose that Bob (admin of www.example.com) wants to get a signed > certificate > for that domain and Eve (from NSA) is trying to get that certificate too. > Eve > can also somehow do HTTPS MITM en route from Bob's computer to the ACME > server > (I will ignore here the possibility of HTTPS MITM en route from the ACME > server > to Bob's server). To make it more realistic [1], let's also suppose that > Bob has > received a signed certificate for www.example.com in the past so that the > validation process involves PoP of previous key / recovery token. > > In that case and with current ACME spec [2], Eve can AFAIK get a separate > signed > certificate without any knowledge of Bob (unless he has access to reliable > public cert issuance records and inspects them). To do this, she could pass > through all validation challenges while substituting her own (independently > generated) public key. The ACME server will then happily validate Eve for > www.example.com and sign her key. > > Then, after Eve got her certificate, she could send some error message to > Bob, > such as "The server is overloaded. Please try again in 5 minutes". To make > it > more realistic, she may send a defer message with a long timeout to Bob > before > that. Bob (or even an automatic script) will then ask for the signature > again > and get it unobstructed. > > To block such an attack, all challenge responses should depend somehow on > the > public and/or private keys of Bob. For example, in the "simpleHttps" > method, the > value provisioned in the file should be signed with Bob's private key. > Alternatively, some time delay between two certificate issuances for > www.example.com could be enforced (e.g. 24 hours). If Bob would have to > wait > that long, he would have begun to wonder what was going on. > > Also, the Recovery Token that is sent from the ACME server should be > encrypted > with Bob's private key so that Eve could not use it later to get a > separate cert. > > > Greetings, > Mateusz > > > [1] Because otherwise almost any Eve that could do MITM can also redirect > all > trafic from ACME server to www.example.com and get a cert that way. > > [2] I meant last version of > https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
