1

I want to make a mobile app secured with SSL pinned. The problem I know I will have is if the certificate expires.

My possible solution would be downloading a certificate from my server from time to time. I think this wouldn't be bad, but what happens if I intercept that initial connection (potencially unsecured), and replace the certificate with a custom one. Is this a valid concern? Is there a way this can be bad for my app?

  • Can't you ship the first certificate hard-coded (as a hash?) in your app? – SEJPM Jun 21 '16 at 21:03
  • Yes, so I can download the new ones secured? But I've been thinking that maybe the best thing is to make the user update the app when the certificate is expired. But for this is necessary to have more than one certificates. What do you think? – facumedica Jun 21 '16 at 21:22
  • You certainly should update the app when you update the cert. Why is this a problem? – Neil Smithline Jun 22 '16 at 1:50
  • @NeilSmithline the problem is because if I update the app (which takes a couple of days to be updated on the stores) the previous version will stop working until the new one is released and the users update it on their devices. – facumedica Jun 22 '16 at 14:22
  • @facumedica have you considered pinning the key instead of the cert? The key can be used in the new cert as well so there is no need to update. This is what HPKP does – Neil Smithline Jun 22 '16 at 14:27
1

Assuming the source of the new certificate is the one you're pinning, and the pinning certificate hasn't been revoked, you're probably OK. At some level, you have to trust the system (EDIT: I mean you have to trust that public key crypto works in general, not that the PKI/CA system in particular is trustworthy), and you're already doing everything you reasonably can to verify the server.

Now, with that said, standard practice is to pin only the public key information (which means you can do things like re-issue the same certificate with a new expiration date, without breaking your pinning) and to pin both the key of your current certificate, and a backup key. The backup key is for if you need to rotate or revoke your current certificate, rather than just re-issuing it. The backup key pair can be created in advance, and then you throw the only copy of the backup private key in a vault or something until you need it.

Between the ability to re-issue certificates so long as you don't change the public key, and having a backup key if you do need to change keys, you should have a large window between when you need to rotate/revoke a key, and when the pinning breaks. During this window, you can release an app update that turns the old backup into the primary key, adds a new backup, and removes the no-longer-trusted primary entirely. If necessary, your app can including a version check function that reminds users to upgrade from the store when the keys change.

  • I have a lot of questions, I've already considered using two certificates or keys (but I don't really know how to generate a public key or compare it with the server). Another question I have is how do I use more than one certificate on my server? An idea I had is to download an encrypted certificate, unencrypt it inside the app, check if it is valid and use it. So I can avoid someone intercepting and putting a custom certificate inside my app. What do you think? – facumedica Jun 22 '16 at 14:27
  • @facumedica: I'm not really sure what problem you're trying to solve here, with the whole "download an encrypted certificate". If you mean you want to be able to update pinned certs "over the air" without an app update, yes, that works. Fundamentally, "download an encrypted <THING>, unencrypt it inside the app, check if it is valid and use it" is what TLS does already; you don't need to do anything extra there. You can put extra validation in for the cert if you want, but if your server has been compromised, or if TLS itself is broken, you're totally compromised and there's nothing you can do. – CBHacking Dec 19 '16 at 18:46

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.