19

I originally posted this question on StackOverflow, but reposted here due to lack of responses.

I am trying to decide if it's a good idea to do ssl pinning in my iOS game that uses a server to deliver content. It seems like it's important, but the one thing that is really bothering me is the thought of the day that the certificate expires. Since the certificate has to be included in the app bundle, this means there will be a point where users will be forced to upgrade. Depending on what Apple is doing at that time, might mean they can't upgrade due to device / os constrictions. So, I am really nervous about putting this in.

Has anyone had any experience with ssl pinning and expired certificates, making this a seamless, no-down-time thing for your users?

patrick
  • 291
  • 1
  • 2
  • 3
  • Do you use a self-sifned certificate for this? If not you could pin the (self-run) CA certificate and the domain name. – SEJPM Mar 21 '16 at 08:57

3 Answers3

11

Your application could store multiple certificates in its pin list. The procedure for changing the cert would then be:

  1. Some time before the certificate expires, release a new version of your app with a replacement cert in the pin list, as well as the original cert
  2. when the old certificate expires, replace it on the server - the app should then still work as the new cert will already be in the pin list
  3. Some time after the cert expires, release a new version of your app removing the old cert

This should reduce the risk of service interruption but does not remove it completely, since some users may not install the new version of your app.

Also, it may not help you in cases where you need to change the server cert in a hurry (e.g. you think the cert may have been compromised).

I have also heard of people who have allowed their applications to update their pin list when connecting over "more trusted" networks. For example WiFi would be less trusted than 3G/4G since it is must cheaper and easier to do a man in the middle attack on WiFi.

On balance and from an operational perspective, I think certificate pinning causes more problems than it solves unless your data is particularly sensitive and confidentiality/integrity significantly outweighs availability in your list of concerns. (I realise I might get some downvotes for this view).

Amit Raj
  • 103
  • 5
Mike Goodwin
  • 2,151
  • 1
  • 11
  • 13
  • 1
    Instead of pinning the cert, you can pin the public key. At that point, you don't need to worry about releasing new versions of your app as long as your SSL certs are created with the same private key. – Sandy Chapman Sep 06 '18 at 13:55
  • 1
    (Very delayed response). @SandyChapman: That is true, but in the case where your cert is compromised, then so is your private key. – Mike Goodwin Jan 09 '20 at 22:10
  • 1
    Yes. It depends on your (or your organizations) opsec. If you can confidently store a private key such that you're sure it's not compromisable, then I'd suggest pinning a public key. Otherwise, enforcing rotations of certs and key is a good practice. – Sandy Chapman Jan 10 '20 at 12:28
1

You sign a new certificate with your intermediate signing key.
Specifically, what's "included in the app bundle" is your root signature verification key.

Community
  • 1
0

I need to assume you are describing Public Key Pinning (HPKP) as documented at https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning (The TLS related activities are quite fast moving these days, so perhaps there's some other SSL pinning being experimented with).

As described in Ricky's answer, you can pin the public key of the intermediate (or even root) certificates, and/or you can pin the "next" CA's key as well. (For example, you can pin the current CA, and the letsencrypt intermediate CA). The danger with this is obviously that there's no guarantee that their next issued certificate will use that specific key at all! And in pinning any other key, you place trust that it will not be the one issuing a certificate for your domain to someone else - the risks are to be weighed by you only. (Some has been bitten by the CA switching to a new key just before renewal).

There's one further option, as the pin is actually about the public key, if you re-issue the certificate with the same public key, then the new certificate will have the same pin hash. The same way, you can prepare the new pin with the new CSR you already generated, but not yet sent to any CA.

chexum
  • 781
  • 6
  • 10
  • are there any security risks with pinning to the public key? Is that some how easier for someone to get around? – patrick Jan 20 '16 at 19:54
  • I don't see how would it make the PKI less secure. By pinning any part of the chain, you're restricting the CA chain to include a key known by you, which *should* make your infrastructure more resistant to the "too many trusted CAs" problem. The only consideration is that, by including a future part of the chain (or the leaf), you may reveal which CA you are going to use after the expiration (or after an emergency). – chexum Jan 20 '16 at 21:31
  • Just curious, how could revealing which CA is going to be used after expiration potentially affect security? – patrick Jan 21 '16 at 20:24
  • I don't think it's a significant problem (and not necessarily a technical one), but if you know a domain is going to use a specific CA, you may be able to know more about how they verify ownership, and block these attempts. For example, if you know I'm going to use letsencrypt, (*and if you have control over that network), you could be able to block their attempts at reaching my hosts. On top, you could tell I'll need to do that every 90 days. If you know I'm doing it automatedly, a simple DOS against the CA could knock my service out. But: too many IFs. – chexum Jan 22 '16 at 18:37