Welcome to part two of this series. First, let’s recap what we learnt in Part One:

1. Why HTTPS is far more secure than HTTP?
2. How can we build a secure connection through SSL?
3. Why are certificates valuable for data protection?
4. How to protect against a MITM attack? 

Now that we have learned about SSL Pinning and how one can acquire a certificate, let us dig deep into what a certificate is and what forms its composition.

Read the fine print: what is a Digital Certificate

A certificate is a file that encapsulates information about the server that owns the certificate. The structure of the certificate uses X.509 standards. X.509 is defined by the International Telecommunication Unions’ Standardization Sector.

A Digital Certificate consists of a variety of information, such as –

1. Subject: Provides the name of the entity (computer, user, network, device, etc.) that is issued the certificate by certificate authorities (CA).
2. Serial Number: Provides a unique identifier for each certificate that a CA issues.
3. Issuer: Provides a unique name for the CA that issued the certificate.
4. Valid From: Provides the date and time from when the certificate becomes valid
5. Valid To: Provides the date and time when the certificate is no longer considered valid
6. Public Key: Contains the public key of the key pair that goes with the certificate
7. Algorithm Identifier: Indicates the algorithm used to sign the certificate
8. Digital Signature: Verifies the authenticity of the certificate
9. Version: Indicates the version number of the certificate
10. TimeStamp: Shows the time when the certificate was created

For more information, please visit the thread here¹.

Commonly used filename extensions for digital certificates (X.509):

1. PEM (Privacy Enhanced Mail): A Base-64 encoding, whose file extension is .pem. The certificate information is enclosed between “ — — -BEGIN CERTIFICATE — — -” and “ — — -END CERTIFICATE — — -”
2. PKCS (Public-Key Cryptography Standards): Used to exchange public and private objects in a single file. Its extensions are .p7b, .p7c, .p12 etc.
3. DER (Distinguished Encoding Rules): A binary encoding, whose file extensions are .cer, .der and .crt.

Now the pressing question— which certificate to pin?

The choice of certificate impacts the level of security achieved. It decreases as we move down towards the Root Certificate. Hence, the developers need to choose carefully.

SSL/Leaf Certificate: This is the most secure option. If you pin the leaf certificate, then you can be sure that the presented certificate is yours. But as mentioned earlier, this creates a problem anytime you want to rotate your certificate. When the certificate is changed, everyone’s application needs to be updated.

Intermediate Certificate: When you pin the intermediate certificate, you are placing your trust in intermediate CA that it will not issue an unauthorised certificate for your server. The advantage of this approach is that you can rotate your leaf certificate as often as you want, as long as you use the same intermediate CA.

Root Certificate: If you pin the root certificate, you are trusting a collection of certificate authorities — the root CA itself as well as any intermediaries it trusts – not to issue unauthorised certificates. This is the least secure option and hence the attack surface is larger.

It is generally recommended to pin multiple certificates to decrease the chances of bricking your application. Pinning intermediate and leaf-level certificates together is the popular approach.

Now let’s find the best approach to pin a certificate

1. Certificate Pinning

In Certificate Pinning, the developer hardcodes the SSL certificate (X.509 certificates) into an application code. When the application communicates with the server, it checks whether the same certificate is present or not. If it is present, the application proceeds with the communication. Otherwise, it will throw an error. The downside to this type of pinning is if the certificates are rotated regularly, then the application needs to be updated regularly too.

2. Public Key Pinning

Here, the underlying public keys are pinned to check the integrity of the connection. This is more flexible but a little trickier due to the extra steps are taken to extract the public key from a certificate.

As with a certificate, the program checks the extracted public key with its embedded copy of the public key. The underlying public keys in certificates can remain static. Hence, it is immune to the certificate rotation problem.

That is all folks. Hope you enjoyed reading about certificates and how they can make your Android experiences more secure. 

If you are interested in identifying and solving problems like these and working with the Android team, connect with Piyush Maheswari on LinkedIn. We are always on the lookout for amazing Android engineers like you, at Zomato.

_{All images are designed in-house.}

-x-

Sources: 

1. Understanding Public Key Infrastructure and X.509 Certificates, linuxjournal.com