You have downloaded and installed your bank's app on your mobile. You want to make some transection on it. When you try to log into it, it connects with the server of your bank. But how do you know the server it is trying to connect is genuine or not?
Let’s first take a look at -- How a request from your mobile app to its back-end server using HTTPS takes place. Without seeing anything happening at the surface, you only know that your client sends a request and the server sends a response. However, great subtlety exists in this exchange than you realize.
Before the client and server exchange application data, a figurative handshake occurs to confirm the client is talking to the right server. This handshake follows these five steps:
-
The client initiates a handshake with the server and specifies a Transport Layer Security (TLS) version.
-
The server responds with a certificate and public key.
-
Then, the client verifies the certificate or public key and sends back a shared key. This shared key is based on the public key from the server.
-
Next, the server confirms receipt of the shared key.
-
And finally, data flows between the client and the server. Both the client and the server encrypt data using the new shared key.
In this example, NO certificate pinning is used. The client does some basic validation on the cert but doesn’t verify that the cert matches any known cert. It checks to see if the cert’s root came from a trusted certificate authority and that the server in the cert matches the server that the client connects to.
Although HTTPS results in much better security than using HTTP, the “bad guys” trying to listen in on your network traffic could still succeed if the trusted certificate provider gets compromised due to a security vulnerability. In fact, many trusted 'Certificate Authority (CAs) have been compromised in past.
So, what do we do to secure our data transmission even more? We pin specific certs that we trust to our client application.
What Is Certificate Pinning?Certificate pinning forces your client app to validate the server’s certificate against a known copy. After pinning your server’s certificate inside your client app, your client should check the basic validity of the cert as in Step No. 3 from the list above, as well as verify that the server’s certificate matches the pinned certificate.
To verify we have a match, the client can validate against the entire cert or against the public key. However, instead of a direct copy of the cert or key, we instead use a fingerprint. A fingerprint is a hashed version of either the entire cert or the public key. If the fingerprints between the server and the client side cert match, the connection is valid. If they don’t match, the app should reject the connection.
Another fun fact—pinning can be preloaded into the application, or it can automatically pin whatever certificate the server sends during the FIRST client-to-server call. Preloading provides the application more protection, whereas an attacker might be able to pin their own certificate upon the first call.
What Should You Pin, A Cert or A Public Key?Typically, security folks advise you to pin the public key. This has a few advantages. First, if you don’t do this and your certificates are rotated frequently, then you will need to push out new pinned certs frequently. In effect, you will have to push more updates of your app, more frequently in the market. However, if you pin just the public key, the rotated cert (new) usually keeps the same public key.
IMPORTANT:
Regardless of what you decides to pin, a cert or a public key, you must consider pinning an (extra) backup cert or public key in case one expires. Do NOT overlook it...
If You Want To Pin A Certification, Then...
Which Cert in the Chain Should You Pin?If you’ve ever opened up a cert, you may have noticed that it’s not just one cert inside.
When creating certificates for your server, you must use, at a minimum, a trusted certificate authority (CA) to build it off of.
However, you can also add more layers into your cert, creating a certificate chain.
I request you to have a look at certificate-chains, so that you can see what will happen if you pin them:
1. Leaf Cert
It is your own server certificate. It is the top level cert in a certificate chain. If you pin a leaf certs to the app (client) then there is an almost complete certainty that the certificate will match. However, the problem will come if you have to cycle your leaf certs often. Then you need to roll out updates fairly frequently to make sure that your customer’s app continues to work.
-----------
2. Intermediate Cert
It lives between the leaf and root cert. If you pin a intermediate cert to the app (client) then you’re putting your complete trust in the intermediate certificate authority (CA). This will allow you to update your server’s leaf cert as and when you require, because the validation of certs will occur at the level of the intermediate cert.
VERY IMPORTANT:
While there must be at least one intermediate cert in a chain, it is also possible to deploy multiple intermediates within a single chain. It is possible, though not recommended, to perform pinning with only the intermediate certificate as you place all your trust in the intermediate CA or CAs.
-----------
3. Root Cert
Finally, the root cert comes from the trusted certificate authority. Pinning the root cert alone puts trust in the root cert authority, as well as all intermediaries that the root cert authority trusts.
Ultimately, you can choose which certs to pin but it is essential for high-security applications to pin at least one certificate in the chain that is controlled exclusively by your organization.
An easy mistake to make would be to pin only the root cert of a public certificate authority (CA). This mistake would allow an attacker who obtains a fraudulent certificate from the same CA and have it accepted by the client as authentic.
-----------
How Do You Pin Certs in Your Mobile App?Many methods exist for actually pinning certs into your application.
You’ll have to choose between hard-coding the cert into your application code or putting the cert pin into configuration files that are bundled in your application at build time. Preferably, you’ll go the configuration route, as that keeps your certs out of your source code repository and away from prying eyes.
Android
Although many more ways exist for pinning certs in your Android app, the following three are most often used:
** • TrustManager: **A TrustManager instance decides whether the app should accept the credentials from the server. This involves multiple changes to your application and can easily be implemented incorrectly, leading to bugs.
**• OkHttp and CertificatePinner: **Using OkHttp for your server calls provides a simple mechanism for implementing certificate pinning. The cert fingerprint should be injected into your application at build time. Then, once you have your CertificatePinner ready, add it to your HTTP client, and you’re ready to go.
**• Network Security Configuration (NSC): **With NSC, you must add certificate pinning into your configuration using XML files that contain fingerprints.
iOS
With iOS, the best option relies on TrustKit, an open-source SSL pinning library. With TrustKit you can implement pinning using simple APIs.
Without TrustKit you may end up implementing from scratch, which can be dangerous. If you don’t know best practices or your design is flawed, you could be susceptible to attacks.
.NET
In .NET, we can pin certificates using ServicePointManager. As with Android’s CertificatePinner, we can hard-code the fingerprint into the source code or pull it from configuration. Again, pulling from configuration at build time is preferred.
While certificate pinning can be effective, it is also quite problematic. It exposes organizations to costly certificate management challenges and potential poor user experiences.
Please let me know of what do you think about this in the comment section. You can also share with all if the information shared here helps you in some manner.
Kindly write your comment on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.This Article Was Written & published by Meena R, Senior Manager - IT, at Luminis Consulting Services Pvt. Ltd, India.
Over the past 16 years, Meena has built a following of IT professionals, particularly in Cybersecurity, Cisco Technologies, and Networking...
She is so obsessed with Cybersecurity domain that she is going out of her way and sharing hugely valuable posts and writings about Cybersecurity on website, and social media platforms.
30,000+ professionals are following her on Facebook and mesmerized by the quality of content of her posts on Facebook.
If you haven't yet been touched by her enthusiastic work of sharing quality info about Cybersecurity, then you can follow her on Facebook:
Click Here to follow her: Cybersecurity PRISM