Android & How to secure it?!
Part I
By making your app more secure, you help preserve user trust and device integrity. Let’s see what can we do to secure it. This will be a 3/4 part series and I’ll try to cover all the topics related to it.
Before we deep dive into how we secure our app, let’s get down to revising some basics.
Let’s understand what are HTTP & 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 the web address. And this indicates that you are now using HTTP to retrieve 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, which includes any text that you type on that website, that information is transferred over 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 Secure Hypertext Transfer Protocol. And this is HTTP with a security feature. Secure HTTP encrypts the data that is retrieved by HTTP and it does this by using encryption algorithms to scramble the data that’s being transferred.
HTTPS protects the data by using one of two protocols. And one of these protocols is SSL. SSL or Secure Sockets Layer is a protocol that’s used to ensure security on the internet. It uses public-key encryption to secure data.
Let’s understand how is a secure connection established between a client and a server using SSL?
The two computers, the client and the server go through a process called an SSL/TLS handshake, which is a series of back-and-forth communications used to establish a secure connection.
The steps involved are (in the simplest form I could find online):
Note: 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 that those digital certificates — certificates, for short — are valid. It also verifies that the server is authentic and not someone who wants to snoop sensitive information.
For more details on this, you can check out this link.
Let’s understand more about Certificates:
A certificate is a file that encapsulates information about the server that owns the certificate. It’s similar to an identification card, such as a passport or a driver's license.
A Certificate Authority (CA) can issue a certificate or it can be self-signed. In the first case, the CA must validate the identity of the certificate holder both before it issues the certificate and when your app uses the certificate. In the second case, the same entity whose identity it certifies signs the certificate.
Now, when you get a certificate from a CA, that certificate is 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. 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 the picture, what is it and why do we need it?
When the 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 provides or Android CA’s provided by Google.
This method has a weakness, however: 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 such an attacker to set up a man-in-the-middle attack(MITM) and capture the transmitted data moving to and from your app.
MITM: As we read, 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 Man-In-The-Middle.
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 out of the band for the website or you can use the OpenSSL client to fetch the certificate.
There is a downside to pinning a certificate. If the site rotates its certificate on a regular basis, then your application would need to be updated regularly. For example, Google rotates its certificates, so you will need to update your application about once a month (if it depended on Google services). Even though Google rotates its certificates, the underlying public keys (within the certificate) remain static.
However, we have a solution to the above downside too, which I will share in the upcoming blog(s).
Now that we know the why and what of SSL Pinning. Hang on for part II, it will be out soon where we’ll get into coding, which everyone is here for.
If you learned something new from this post, don’t forget to hit the 👏 icon. Stay tuned for the next one!
More details on me: Here.
