Barry O'Rourke
Devops just mailed to say they will rotate the certificates on all of the endpoints today
, mentioned the Engineering Manager at one of our customers, that’s unexpected, I wonder what happened.
Now this is someone responsible for an app with over 1M customers which uses Certificate Pinning to lock itself to the certificates of several endpoints across multiple hosts. You would think I might detect a note of panic in his voice at this point.
Sure enough he asks: You are sure this pinning setup of yours is going to work, right?
I make suitably soothing noises and sure enough a few hours later I get a :thumbsup: over Slack. All is well.
I have documented the difficulties associated with pinning previously and Google's recent announcement effectively killing off HPKP in browsers cited fundamental key management difficulties as a central issue. Despite this, certificate pinning is a vital mobile security feature for any app where sensitive data, either the users or the API owners, is transmitted. Alternatives are required.
The fundamental difficulty is distribution of certificates to the client. This must be secure, so baking a static certificate into the app at build time, but must support key rotation, requires app releases to synchronize with devops and forces users to upgrade. HPKP, designed for web browsers, is based on a “remember first visit” model where the certificate to pin against is downloaded and marked as valid for a certain period. This breaks the dependency between client and server certificates but implies a very will planned key rotation strategy and when badly configured could result in the site owners losing control over it.
The basic soft pinning approach does have a certain “better than nothing, I suppose” appeal to it. An app developer might consider simply pinning to the certificate first presented from a server at first contact after app startup and hope it is genuine and that a MitM would only be encountered later on some other network. Server side certificate changes could be reloaded with app restart. These should be rare enough that they could be flagged as a security events urging the user to be cautious. If you suddenly get the message in a coffee shop, maybe wait till you are on another network or use GSM to access the service for example.
Clearly this is not going to cut it if you really want to lock down the API connection (not to mention provide non-rubbish UX). Fortunately, if you are an Approov subscriber, you have another option.
The MitM Detection features of Approov are a little complex, although they can still be explained in under 7 minutes, but in essence provide 2 things to your app via the Approov SDK interface:
- The leaf certificate for your endpoint, via the getCert(String url) call.
- A JWT with a valid signature only if the leaf certificate actually matches that fetched from the endpoint by the Approov server.
So now we have a certificate to pin against, in exactly the same way as before in soft pinning, but we also have information about whether a MitM attack has compromised that initial certificate. For security the app cannot know if the JWT is valid or not, only your API has the secret to check the signature with, so care must be taken not to transmit anything sensitive from the App until the server gives it the go ahead. So now we have the following capabilities against MitM.
- An app that can detect a MitM attack occurring anytime after the first endpoint access.
- A certificate validation mechanism which allows the API to detect when the connection from the app has been compromised.
- A certificate distribution mechanism which automatically (or on demand) fetches the latest endpoint certificate.
These capabilities allow app developers to build robust, dynamic pinning into their apps providing a high level of MitM protection but avoiding the logistical nightmare that is static pinning.
So if you have been putting off deploying Certificate Pinning due to its complexity why not give Approov a look with a free evaluation.
