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.

Suppose I am setting up an IPsec VPN for Apple iOS clients with the requirement that the iOS clients need to know that the server is legitimate and vice-versa.

I create a root CA and issue a certificate for the IPsec server. The CA certificate is installed on the iOS device.

In the case of a man-in-the-middle attack will other servers be able to impersonate my IPsec server using a certificate signed by another or rogue root CA?

share|improve this question
    
You have numerious grammar mistakes which makes it very tough to understand what you are asking. –  Ramhound Feb 21 '12 at 19:24
    
I re-wrote the question –  Hilt86 Feb 21 '12 at 21:14
add comment

1 Answer

up vote 1 down vote accepted

I don't know about the specifics of iOS, but the principle should be the same.

In theory, if you get your clients to install and trust your CA certificate, then any certificate it issues will be trusted by those clients. A man-in-the-middle attack should not be able to forge these certificates, unless they grab hold of your CA private key. So in that respect, your solution should be protected against man-in-the-middle attacks.

The downsides of using such solution, as opposed to getting a certificate issued by one of the trusted root CAs is with:

  1. Deployment : With your approach, you'd have to manually installed your own CA as trusted on all your devices. Users with other devices (without your CA certificate) won't have this installed and either won't connect, or will manually have to accept an unknown (and therefore untrusted) certificate. In which case, the man-in-the-middle attack is a real possibility.
  2. Revocation : What happens if your CA or server private key gets exposed somehow. How can you tell all your devices not to trust it any more, and instead trust a new certificate? 3rd party trusted CAs usually provide service to perform revocation checks to avoid this. You might be able to do something similar on your own, but it increases the complexity dramatically
  3. CA Security : Whilst this is not guaranteed, trusted certificate authorities are likely to have stricter security in place. This is their core business after all.
  4. Price/Hassle : I imagine the cost of issuing a certificate to your server with a 3rd party trusted CA should be significantly lower than running this whole thing by yourself. This of course depends on your circumstances, e.g. how many devices, what security/resources you already have etc.
share|improve this answer
    
Let me clarify; if thawte and myCustomCA both generate a certificate which one will iOS use? –  Hilt86 Feb 22 '12 at 0:36
    
not sure I understand the question. I would expect Thawte's root CA to be installed already on iOS, so any certificate it issues will be considered 'trusted'. For myCustomCA - you'd have to install it manually. –  Yoav Aner Feb 22 '12 at 7:27
    
If the iOS device has the Thawte root CA and myCustomCA installed which root CA will take precedence? I'm trying to prevent nation-state actors (iran / UAE / whatever) from being able to forge a cert and to be able to decrypt our traffic. –  Hilt86 Feb 27 '12 at 9:37
    
There's no precedence. Each end-certificate (e.g. for your IPSec endpoint) is signed by a particular CA, which might be within a chain of CAs going up to one root CA. If this root CA is installed on the device then any certificate issued by them will be considered trusted. If you want to use your own certificates, and don't trust Thawte etc, then you'd probably want to install your own root CA on all devices and sign your own server certificate using this CA. –  Yoav Aner Feb 27 '12 at 9:54
    
Ok that makes sense and seems obvious at this point - thanks for your help! –  Hilt86 Feb 27 '12 at 21:50
add comment

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.