Re: [Acme] Stronger protection against HTTPS MITM

[Richard Barnes <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>