Take the 2-minute tour ×

The question I have is simply how do I prevent a MiTM attack on a certificate once the server side creates a new one and tries to send it to a client? Does the certificate get encrypted by rsa and sent or...

share|improve this question
You first need to get your basics right.I would recommend you to read 'cryptography and network security' by William Stallings –  Shurmajee Apr 8 '13 at 12:39
Which chapter? Please don't tell me start at chapter one. –  lost_with_coding Apr 8 '13 at 12:43
I can't believe you asked that.if you have not read the initial chapters start from the very first page. If you know the concepts you will get through them quickly.don't be lazy –  Shurmajee Apr 8 '13 at 12:46
Well yeah the first 3 chapters are ridiculously easy as I can see now. –  lost_with_coding Apr 8 '13 at 12:53
add comment

2 Answers

up vote 2 down vote accepted

You have two potential attacks:

  1. The attacker poses as a fake server, and talks to the genuine client, feeding him a wrong certificate or other nefarious data.

  2. The attacker poses as a fake client, and talks to the genuine server, obtaining a valid certificate with the genuine client's name but the attacker's key in it.

A man-in-the-middle attack is when the attacker does both simultaneously. However, each attack is problematic in its own right.

Defeating the first attack (impersonation of the server), use the standard mechanisms: have the server use a certificate, issued by a well-known CA, that the client trusts. All HTTPS Web sites do that. This is how, when you connect to https://www.paypal.com, you get the nifty padlock icon and know that you are really talking to Paypal's server.

To defeat the second attack, well, it is up to you: the server is creating and sending a certificate to "a client who just connected". How does the server know what to put in the certificate ? From where comes its knowledge of the client's identity ? If, for instance, the "genuine client" is authenticated by virtue of having been granted a one-time registration password, then the communication will occur within a HTTPS connection. In that connection (where the server is verified as "true" by the client, see above), the client sends its one-time registration password, and the server, from that point onwards, knows that it is talking to the expected client, and can send him a certificate or whatever it wishes to send him.

share|improve this answer
", knows that it is talking to the expected client, and can send him a certificate or whatever it wishes to send him." So the certificate does not need to be encrypted at all. I just want to make sure I understand that part properly. –  lost_with_coding Apr 8 '13 at 13:16
A certificate is public data. But it is mathematically linked with a private key, which should be well-protected; if you generate it server-side, then its transmission to the client shall be encrypted. Anyway, this is a non-issue: you do the whole protocol in SSL (if you do not, then you have other bigger issues, such as hostile hijacking of the connection after the one-time-password authentication). –  Tom Leek Apr 8 '13 at 13:26
Ok, The certificate is public data, that I do understand. Like I know how RSA works by the way. –  lost_with_coding Apr 8 '13 at 13:29
@lost_with_coding I have to add to Tom Leek's statement. What you should actually do is save the certificate in PKCS-12 file format. Also sign and encrypt this file and then send it to the client. You can use a web form over SSL to have the client choose the password for the PKCS file. Also, like Tom said, send it to the client over SSL as well. As a client you can be assured that there was no MITM attack because the certificate that you receive is properly signed by the expected CA. –  KyleM Apr 8 '13 at 14:57
add comment

Use HTTPS as Tom Leek suggested in his answer. Additionally, request a password from the user and send them back an encrypted PKCS-12 formatted file that is encrypted using the password that you got from the user. The PKCS-12 file will contain the user's certificate and private key. Optionally, you can also sign the PKCS-12 file using your server's certificate, although I don't think that's necessary because the certificate contained within the PKCS-12 file is already signed by a trusted, valid CA.

I posted this as a separate answer because I don't consider it sufficient to send private keys over SSL when there is a standard procedure known as PKCS-12 that is used to protect the keys in certain cases, such as when you send it over unsecure networks. However, if your only goal is to defeat a MITM attack, Tom Leek's answer may be sufficient. If your goal is additionally to securely send a certificate and private key, then I suggest this answer.

share|improve this answer
add comment

Your Answer


