Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

2 Answers 2

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

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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