3

By looking at https://letsencrypt.org/how-it-works/, I got the feeling that a man-in-the-middle attack might be possible in the 'Domain Validation' phase.

During that phase, the admin is asked to e.g. perform the challenge of putting a file on the webserver and sending a signed nonce to the CA. What if a man-in-the-middle generated his own (authorization) key pair (while the admin is performing the domain validation) and signed the nonce with the malicious key pair? The admin would have performed the challenge by posting a file on the server and the CA would have gotten a maliciously signed nonce (if the man-in-the-middle is able to discard the signed nonce from the admin). This would mean a compromised authorization key in control of the man-in-the-middle for a domain.

The solution (in my opinion) would be to simply post the signed nonce on the Website (on a path decided by the CA) instead of sending it to the CA, such that the "signature swap" cannot happen. This however is not depicted on the Let's Encrypted "How it works" explanation.

Am I understanding something wrong or how is such an attack prevented?

NightRain23
  • 131
  • 2

2 Answers2

1

From https://letsencrypt.org/how-it-works/:

Let’s Encrypt identifies the server administrator by public key. The first time the agent software interacts with Let’s Encrypt, it generates a new key pair...

Although it doesn't say it explicitly, the server admin must send the public key to Let's Encrypt at this point (otherwise, it's impossible to see how the later digital signature verification would work). So, this is the public key that Let's Encrypt would use to verify the digital signature on the nonce. Therefore, in your scenario, if a rogue actor were to create his own keypair and use his private key to sign the nonce, the signature verification would fail because the public key that Let's Encrypt would use to verify the signature would not correspond with the private key used to create the signature.

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • What if the man-in-the-middle swapped the public key of the admin with his own (malicious) public key at the beginning also? To be more precise: how does Let's Encrypt verify the identity of the admin? – NightRain23 Nov 17 '19 at 12:02
  • 2
    @NightRain23 traffic to LetsEncrypt uses https, only the file used for the actual domain validation is via http. – Jack Nov 19 '19 at 01:58
1

From the Let's Encrypt Documentation:

Let’s Encrypt identifies the server administrator by public key. The first time the agent software interacts with Let’s Encrypt, it generates a new key pair and proves to the Let’s Encrypt CA that the server controls one or more domains.

Identifying someone by the Public Key isn't put entirely correctly phrased. The server administrator is of course verified by his private keys signature and Let's Encrypt only verifies that signature using his public key.

Along with the challenges, the Let’s Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair.

This is called proof of possession (POP). By signing a nonce Let's Encrypt provides the server is demonstrating that it holds the private key to whatever public key it will later use to authenticate against Let's Encrypt services. Unless the private key of the authentication key pair gets into the hands of an attacker, no certificates can be issued by some sort of man-in-the-middle.

Summarizing this:

  1. Client server create public and private key
  2. Let's Encrypt sends some nonce
  3. Client server signs the nonce with the private key
  4. Client server sends the signed nonce and the public key
  5. Let's encrypt verifies the signature on the nonce with the public key from client server

Steps 2 to 5 are repeated every time the client server now requests a certificate, only that the public key doesn't need to be sent by client server anymore, as Let's Encrypt has kept it for verification of authentication.

Seb_Schulz
  • 404
  • 2
  • 4