Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 1 down vote favorite

My mobile (iOS and Android) connects to my server via a REST API over HTTP. I would like that HTTP to be secure, so HTTPS seems to be the obvious choice. All of the questions about self signing SSL certificates warn about how users of the a website won't trust you if you self-sign and they don't know you. But in this case, I don't need my users to trust me, but rather the app has to trust me. Are there any problems with this approach or should I just fork out the money to one of the CAs so I don't have to worry about it?

share|improve this question
Thanks for the response, but I'm not asking about client implementation, but rather the security of the system. – Max Dec 4 '12 at 13:26

3 Answers

up vote 2 down vote accepted

For your particular use case, a self signed cert would be fine.

As you control the app, you do not have to use certificates recognized by browsers, which is the key point of a certificated by a trusted CA.

Functionally, there is no difference in security. See: Does Self-signed certificate differ from CA from a security point of view?

share|improve this answer
up vote 2 down vote

Security of the system is dependent on client implementation. All a certificate inherently does is provide an "agreed encrypted communication protocol". How secure the communication is in actuality is whether or not there is someone playing "man in the middle".

So how do you verify that the certificate received is the same certificate that the source wants you to use? That's either through a 3rd party verifier (which is what comes with payment to a CA) or through the client who (from a previously hard coded implementation) already whats what the cert should look like.

gluck!

share|improve this answer
up vote 1 down vote

You can get a SSL cert for something like $10. Not getting one creates far more hassle than that money is worth.

You can write code to securely verify the self-signed SSL certificate in your app, but the potential for making mistakes is greater than zero, and therefore not really worth it.

share|improve this answer
Keep in mind that a $10 SSL cert isn't likely to be for a particularly reputable CA, though. – Polynomial Dec 4 '12 at 13:35
A valid SSL cert is a valid SSL cert. If the root is trusted by the client/browser, there's no difference. – Joel L Dec 4 '12 at 13:36
Precisely. A lot of less-reputable CAs don't make it into some devices, whereas the big CAs (e.g. Verisign / Globalsign) are highly likely to be in all of them. Plus you'd figure that the big authorities are the ones to be throwing lots of money at HSMs and other expensive security measures. – Polynomial Dec 4 '12 at 13:38
Please give me some references about real, and at least somewhat-popular CA-s that are not supported by actual clients? Of course there are differences in security measures, but in real usage (especially for a mobile app API) a $10 Comodo cert is no less secure than a $1000 Verisign Extended Validation certificate. – Joel L Dec 4 '12 at 13:43
1  
I don't see why a $10 SSL cert will make a difference over a self signed one in this case. If you aren't using a browser for the HTTPS connection, you are going to have to write code to verify the cert anyway. – Terry Chia Dec 4 '12 at 14:00
show 5 more comments

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.