Certificate Pinning and Failing Open

SSL is nice, but there are risks of fraudulent certificates being
issued by rogue certificate authorities. One approach to dealing with
this risk is to use certificate pinning, teaching your Android app
details about the expected SSL certificate, so the app can fail if it
encounters a fraudulent one. This reduces the risk of somebody with
a fake cert intercepting your communications. However, it can increase
other risks, as Square���s Jesse Wilson pointed out earlier today.

For example:

If you pin to your own certificate, that works, until you need to
replace that certificate, because it is expiring or for other reasons
(e.g., the Heartbleed attack ���OMG replace all teh certs!��� response)

If you pin to some other certificate up the chain towards the CA���s
root certificate, that works, until the intermediary needs to replace
the certificate

I imagine that this is why Android 7.0���s
network security configuration���s
certificate pinning implementation fails open. In other words, when
you put an expiration date on a pinned certificate, when that date arrives,
that pin is ignored. For planned certificate obsolescence ���
such as the certificate���s own expiration date ��� this will allow your
app to keep working, even for those users who failed to update their
app. Users who update their app can be moved over to a new pin for a new
certificate. Since CWAC-NetSecurity
is a backport of Android 7.0���s network security configuration, it too
supports expiring pins.

If you elect to pin certificates, whether using network security configuration
or something else:

Set an expiration date on the pin, and fail open. Yes, this reduces
security, but only for those users running older editions of your app.

Have a plan for an emergency app update, in case you need to replace
the server���s SSL certificate in a hurry (e.g., Heartbleed-style
scenarios).

For a server that only handles mobile apps, not Web browsers, you could
avoid some of this by switching to a self-signed certificate and effectively
���pinning��� to that. Since there is no certificate authority in the mix,
you are not at risk of a certificate authority screwing up, being hacked,
or being suborned into issuing a fraudulent certificate.
Remember: the rationale
behind a certificate authority is to help the user with a generic client
app (Web browser) determine if a certificate is valid. It does not add
as much value in scenarios with a specific client, such as an Android app
dealing exclusively with your server.