Giving Android a security boost (Part One)

By making our app more secure, we help preserve customer trust and device integrity. 

This article talks about several tips on how to secure your Android experience. Before we deep dive into the process, let’s start with revisiting some basics.

Understanding HTTP and HTTPS

HTTP stands for Hypertext Transfer Protocol. It is the protocol that is used for viewing web pages on the internet. So, when you type in a web address, like google.com, you’ll notice that HTTP is automatically added at the beginning of a web address. And this indicates that you are now using HTTP to retrieve/ load this web page.

Now in standard HTTP, all the information is sent in cleartext. So all the information that is exchanged between your computer and that web server includes any text that you type on that website. This information is then transferred to the public internet. And because it’s transferred in clear text, it’s vulnerable to anybody who wants it, such as hackers.

And this is why HTTPS was developed. HTTPS stands for Hypertext Transfer Protocol Secure. This is HTTP with a security feature. Secure HTTP encrypts the data that is retrieved by HTTP by using encryption algorithms to scramble the data being transferred. In layperson terms, it gives an extra shield of protection to your data.

HTTPS protects the data by using one of two protocols. One of these protocols is SSL. SSL or Secure Sockets Layer is a protocol used to ensure data security on the internet by use of public-key encryption.

Building a secure connection: the SSL connect

Two computers, one of a client and the other of a server go through a process called an SSL/ TLS (Secure Sockets Layer/ Transport Layer Security). Consider this a series of conversations between the two computers, where SSL works back-and-forth to establish a secure connection.

During the above process, the server responds with the selected cipher suite and sends one or more digital certificates back to the client. The client verifies if those digital certificates are valid and if the server is authentic and not someone who wants to snoop on sensitive information.

For more details, please check out this link¹.

Certifying information  

Certificates are files that encapsulate information about a server. These certificates are owned by the server and work similarly to an identification card, such as a passport or a driver’s license.

A certificate can either be issued by a Certificate Authority (CA)² or it can be self-signed. In the first case, the CA must validate the identity of the certificate holder once before it issues the certificate and once when the holder’s app uses the certificate. In the second case, the same entity that issues the certificate can sign it and validate it for use.

Now, when you get a certificate from a CA, it becomes part of a chain of trust³ or a chain of certificates. The number of certificates in the chain depends on the CA’s hierarchical structure. 

The two-tier hierarchy is the most common form. An issuing CA signs the user’s certificate and a root CA signs the issuing CA’s certificate. The root CA is self-signed and the app must trust it at the end.

Where does SSL Pinning come into play?

When an app tries to establish a connection to a server, it doesn’t determine which certificates to trust and which not to. The app relies entirely on the certificates that the iOS Trust Store or Android CA’s (by Google) provides. 

However, this method has a weakness: an attacker can generate a self-signed certificate and include it in the iOS/Android⁴ Trust Store or hack a root CA certificate. This allows an attacker to set up a MITM (man-in-the-middle) attack and capture the transmitted data moving through your app.

What is a MITM attack?

The TLS standard is based on X509 Certificates and asymmetric encryption. Simply replacing the protocol name will enable encryption, but the app will trust every certificate issued by the server. This means that the attacker can generate their own fake certificates. The certificates will then allow the hacker to intercept encrypted communication. This kind of attack is called a man-in-the-middle attack.

Here’s where SSL Pinning comes into the picture. We should use the SSL pinning technique as an additional security layer for application traffic and validate the remote host’s identity. If we do not implement SSL Pinning, the application trusts a custom certificate and allows proxy tools to intercept the traffic.

SSL Certificate Pinning, or Pinning for short, is the process of associating a host with its certificate or public key. Once you know a host’s certificate or public key, you pin it to that host. In other words, you configure the app to reject all but one or a few predefined certificates or public keys.

Instead of pinning a public key from a certificate, the complete certificate can be used to verify the identity of the host. The advantage is that the certificate is easiest to pin. You can fetch the certificate either through the band of the website or use the OpenSSL client.

There is a downside to pinning a certificate. If the site rotates its certificate regularly, then your application would need to be updated regularly. For example, Google rotates its certificates, so you will need to update your application once a month (if it depends on Google services). Even though Google rotates its certificates, the underlying public keys (within the certificate) remain static.

That’s all folks! For now. We will continue learning more about certificates in Part Two. 

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

-x-

Sources: 

1. What happens in a TLS handshake? | SSL handshake, cloudflare.com
2. Certificate Authority, wikipedia.org
3. Chain of trust, wikipedia.org
4. Official List of Trusted Root Certificates on Android, digicert.com