Subject: [Acme] Stronger protection against HTTPS MITM

From: Mateusz Jończyk <[email-masked]>
Date: Sun, 25 Jan 2015 09:59:50 +0100

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 26 Jan 2015 05:33:11 -0500

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-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Mateusz Jończyk <[email-masked]>
Date: Mon, 26 Jan 2015 17:09:03 +0100

W dniu 26.01.2015 o 11:33, Richard Barnes pisze:
> 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!
> 
> 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
> 

I have been thinking about this a bit and have some more crazy ideas:
- why don't we simply demand that a new key is signed with the old one? It's
AFAIK quite standard with key management.

It could be more robust then the current proofOfPossession validation method
(and is very secure even without HTTPS).

- at first use of ACME, the server could validate another key, that would be
only used in the proofOfPossesion method. It wouldn't be deployed on the HTTPS
server and therefore it would be more difficult for an attacker to get it (e.g.
through some recent bug in OpenSSL). In case of that key, longer key lengths
could be used, e.g. 4096 bits could be required.

It may make more sense when the keys are exchanged e.g. once a month or even
every several days (I've seen such proposals as a replacement to key rev lists,
which are currently not very reliable). An attacker that gets access to the
private key will have only a small amount of time to use it.

- the client could send his IP address to the server (possibly as some
validation challenge response) to verify that the client's and server's ideas of
it are the same (and some DNS hijacking isn't going on).

- would it make sense to support the client specifying more stringent
requirements for future key renewals - such as blocking some challenge
combinations that it considers insecure?
	- it may be helpful in the future when new, more secure validation challenges
will be specified and some older clients will not support and the ACME server
will not require them therefore (or some challenges may be specified that will
be more secure but problematic in use),
	- it can be probably easily added in the future, when need arises so I do not
think that it should be added now in order not to overcomplicate the protocol,

- would it make sense to add to the challengeRequest message some information
about the certificate type that is requested, for example an "extended
validation" certificate?

Greetings,
Mateusz

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Jan 2015 13:20:37 -0500

What is the attack model here? What form of attack is unacceptable?

We have a request for a cert for www.example.com to Alice-Cert. What
attacks do we consider problems?

1) The holder of www.example.com did not authorize any cert binding to that
private key.

2) The holder of www.example.com authorized a cert for that key but it was
for Bob-Cert.

3) The holder of www.example.com thinks they are connecting to Alice-cert
but they are actually connecting to Mallet-Cert.

(1) is very clear problem but (2) is not unless there is an application
that makes use of the certificate without a private key or vice versa. (3)
is going to be trivially solved by checking the issued cert chain.

TLS does not permit certificate substitution attacks.

Binding every communication to a private signing key held by the applicant
is a good idea. Requiring that to be the private key in the cert is a very
bad one. Not least because once we stop using RSA, encryption keys and
signature keys become two different algorithms and there are good privacy
reasons to prefer a key agreement based on encryption and an ephemeral
rather than signature and an ephemeral.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 26 Jan 2015 19:46:53 +0100

http://www.ietf.org/mail-archive/web/acme/current/msg00203.html
Key attestations rocks :-)

On 2015-01-26 19:20, Phillip Hallam-Baker wrote:
> We have a request for a cert for www.example.com <http://www.example.com> to Alice-Cert. What attacks do we consider problems?
>
> 1) The holder of www.example.com <http://www.example.com> did not authorize any cert binding to that private key.
>
> 2) The holder of www.example.com <http://www.example.com> authorized a cert for that key but it was for Bob-Cert.
>
> 3) The holder of www.example.com <http://www.example.com> thinks they are connecting to Alice-cert but they are actually connecting to Mallet-Cert.
>
>
> (1) is very clear problem but (2) is not unless there is an application that makes use of the certificate without a private key or vice versa. (3) is going to be trivially solved by checking the issued cert chain.
>
> Binding every communication to a private signing key held by the applicant is a good idea. Requiring that to be the private key in the cert is a very bad one. Not least because once we stop using RSA, encryption keys and signature keys become two different algorithms and there are good privacy reasons to prefer a key agreement based on encryption and an ephemeral rather than signature and an ephemeral.
>
>
>

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 27 Jan 2015 10:17:36 +0100

W dniu 26.01.2015 o 19:20, Phillip Hallam-Baker pisze:
> We have a request for a cert for www.example.com <http://www.example.com> to
> Alice-Cert. What attacks do we consider problems?
> 
> 3) The holder of www.example.com <http://www.example.com> thinks they are
> connecting to Alice-cert but they are actually connecting to Mallet-Cert.
> 
> 
> (1) is very clear problem but (2) is not unless there is an application that
> makes use of the certificate without a private key or vice versa. (3) is going
> to be trivially solved by checking the issued cert chain.
> 
I was thinking about some publicly unknown vulnerability in TLS or its
implementations. So (3) above.

> Binding every communication to a private signing key held by the applicant is a
> good idea. Requiring that to be the private key in the cert is a very bad one.
> Not least because once we stop using RSA, encryption keys and signature keys
> become two different algorithms and there are good privacy reasons to prefer a
> key agreement based on encryption and an ephemeral rather than signature and an
> ephemeral.

I'm sorry, but I don't understand the above paragraph (most importantly, its
context). What are You responding to?

Greetings,
Mateusz