0
$\begingroup$

While obtaining digital certificate the applicant trusts the certificate authority (or registering authority) as CA is digitally certified (and applicant has CA's public key).

To certify a domain the protocol would go like this:

  • I generate my public-private keys and send the authority my public key encrypted by its public key.
  • She encrypts a nonce and sends me to put on my website
  • As I'm in control of the website I put this nonce and encrypt it with her public key
  • She checks and issues me a digital certificate for that site.

Is there a possibility for MIM attack here as follows:

  • attacker between me and the CA can pretend to be me and requests certificate for domain I control. He generates his public-private keys
  • he intercepts the nonce sent back by the CA
  • he mimics my site and puts on the received nonce
  • CA issues the certificate to the attacker?
| improve this question | |
$\endgroup$
  • 3
    $\begingroup$ That's entirely possible. With DV - domain validation, the certificate is issued to whoever controls or appears to control the domain/server. $\endgroup$ – DannyNiu Oct 29 '17 at 13:13
  • $\begingroup$ I don't think this scheme will add any security above what is already there (using the normal certificate requests and validations). It still depends on the control of the website or - more precisely - server address, as DannyNiu already commented above. $\endgroup$ – Maarten Bodewes♦ Oct 29 '17 at 14:30
  • $\begingroup$ Hi Maarten. This is a certificate request and validation procedure scheme. What do you meen by NORMAL certificate request and validation? $\endgroup$ – croraf Oct 29 '17 at 14:33
  • $\begingroup$ Sorry, I was not aware that you need to encrypt / decrypt nonces during normal certificate requests. I'll check into it. I'm rather more accustomed to private PKI schemes. Could you point out a policy where nonces need to be encrypted, e.g. by one of the major CA's? $\endgroup$ – Maarten Bodewes♦ Oct 29 '17 at 15:07
  • 1
    $\begingroup$ OK, yes, that's clear. OK, so this would be one way to check if the domain indeed belongs to the person requesting the certificate. It's not perfect, and it won't completely protect against man-in-the middle. However, as long as the admin computer is not hacked and the connection from the CA to the server is relatively secure (usually they are directly connected to an internet hub) it provides more security than without the challenge / response protocol. $\endgroup$ – Maarten Bodewes♦ Oct 29 '17 at 19:28
1
$\begingroup$

Yes, that man in the middle attack is possible. The problem is that there is no direct way of providing initial trust to the CA. As long as that is not possible - traveling to the CA is rather expensive - there can be no complete trust.

The validation relies on the DNS and the fact that servers generally are on relatively secure connections. I presume that the CA itself doesn't run on public WiFi either. The challenge response protocol makes sure that you have control over the domain. It also makes sure that the challenge (nonce) cannot be copied without having the private key. But in the end it is protection so that nobody can initiate the connection with the CA

And that's what this protocol really does; it makes sure that somebody else doesn't request a certificate in your name. The amount of protection against man-in-the-middle is very limited. If the server or admin PC is hacked then an attacker will of course have little problem performing the steps himself.

Don't do these steps from an insecure PC or over an insecure connection and make sure that your server and server connection are secure as well. Otherwise the chances of MiTM are heightened. Note that this will still take an active attack, and I presume you checked that the connection to the CA is performed over TLS (right?).

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.