Sachin Rajput · Follow
Published in · 7 min read · Feb 6, 2021
--
As Android developer, our apps feel like our babies to us and obviously, we need to protect our apps layer by layer or as much as we can till we are ensured that our app is safe.. isn’t this thought feels familiar — what we always feel when we are making an app, well most of us feels the same.
And in this post, We are going to simulate a journey, in which we start making an app, and then at times, we come near to this golden lovely RELEASE DAY and we get a thought okay now features are implemented (Product is cooked now let’s serve it better.) and it’s an amazing feeling.
It’s precisely like hosting a dinner at home for our friends and Now Food is ready we need to serve it diligently then what we do we start doing everything we can to make this evening(App_release) smooth and uninterrupted.
To Make our app release uninterrupted we have so many points few of the most used I will be covering today, here is the list of a few of the things we can do to ensure our app more secure stable robust :-
Use of Proguard: it will help us Shrink, obfuscate, and optimize your app. It will also help us in reducing the chances of reverse engineering on APK provided.
(I wrote about a journey for implementing the Proguard already, so please check that here in case you want to explore more on this feature.
Use of HTTPS: “Secure Connection with Server this is also a must.” and HTTPS ensures us that it protects the integrity and confidentiality of data between our App and our Server.
But is using HTTPS protocol for APIs used by our App is enough?
Well, Users expect a secure and private online experience when using an App. and using HTTPS results in much better security than using HTTP but sadly HTTPS is not enough alone to protect our app from Bad guys
e.g) Thor is still nice barehanded but awesome with his Mjolnir/Stormbreaker
- it’s because any Middle Man can come in between our App and our Server and manipulate data/requests and our product control can go in bad hands.
As this picture explains itself sometimes There can be an imposter man (know as A man-in-the-middle) who can attack and take over our connection by impersonating both parties(App&Server) and gains access to information that is shared either from ‘App to Server’ or from ‘Server to App’.
Now the question is how to prevent this kind of interruptions and hostile takeover of our secure HTTPS connections?
and the answer is SSL Pinning.
SSL (Secure Sockets Layer) is a protocol for establishing authenticated and encrypted links between networked computers and servers.
How SSL Pinning will help to get rid of Middle Man attack
SSL encrypts the data exchanged between our server and app, and the attacker middle man can’t view the actual data transmitted. Actual data exchanged will only be visible to our Server and App.
It is a process where we can check the authenticity of a HOST by checking its core X509 certificate. This X509 certificate is the integral part of SSL. we can find more about it here X509 certificate.In Simple words, SSL pinning is a process which forces our client App to validate the server’s certificate against a known copy.
i.e.) we have a known KEY of our server’s certificate stored in our app (like we can store in strings or constants in some file) and then when we try to establish a connection with our server (means hit any API call), first we try to check if the connection is secure by matching the KEY we have in our app with Server’s certificate’s KEY.
“If these both keys matches we are good to go our App connection is with our known(our own) Server”
Okay, let’s see this screenshot.
For example, if we open medium.com (website) inside safari and we click on the lock icon on top (indicated by arrows) so this dialog will slide down with the certificate information.
Every Hosted WebUrl has three kinds of certificates:
- Leaf Certificate.
- Intermediate Certificate.
- Root certificate (also known as Certificate Authority or CA)
we have these three certificates for every endpoint URL, and we can use any of these certificates’ KEY to check with our server’s certificate while making a connection.
this certificate has a hierarchy, and these hierarchies impact the achievable Security.
Leaf certificate is on our own Server level. If we pin against this leaf certificate that means we already are certain that this is our own certificate used by our own company’s personal data servers.
It has one problem though… Leaf Certificate has a short expiry time (like approx 1 year) so If we pin this and use the KEY provided from this certificate in our App, then once it expires our backend Server gets a new Leaf Certificate hence new KEY, that time our app is blocked we need to update another APK of our app by adding this new KEY generated by newly issued Leaf Certificate.
If we use an Intermediate Certificate so we are relying on the company where our backend server is hosted. for eg.) baltimore cybertrust, AWS, GoDaddy, etc.
this is also known as Certificate Authority(CA), if we pin against this Root Certificate, that means we need to use the Certificate key of the Hosting service provider.
The benefit of using the Pinning to Root Certificate is it has a good long life (approx 10+ years) it will not expire soon hence we no need to worry to upload a new APK again and again just because our certificate expired and we got a new one with a new respective KEY.
Okay for example consider, If our backend is hosted on AWS, and we want to do pinning against the Root Certificate of our backend server so we can use the Key of AWS Root Certificate CA.
let’s take it slow, consider this once again.
our own backend Server is also hosted somewhere like AWS right?
so now our server URL endpoint will also have three certificates.
So its up to us to which certificate we want to do SSL Pinning. in general we cam do pinning on Root Certificate as it will not cause us any trouble to change certificate or respective KEY again and again, we also have our preference if we want to do pinning against one or more than one of these certificates.
there are many ways to implement it like:
- We can add it in Retrofit with OkHttp using CertificatePinner.
- We can use network_security_config.xml.
we need OkHttp & Retrofit dependencies added in our project ( mostly we all use these two famous libs, if not just add the Gradle dependencies.)
then okhttp class has this okhttp3.CertificatePinner, we need this only to add any certificate’ key.
We can also achieve SSL Pinning with network_security_config.xml, for this these are the steps:
1.first we need to create an XML folder inside our res directory and create a file called network_security_config.xml inside this XML folder.
2. then we need to add our YOUR_ENDPOINT_HERE inside domain tag, with the value of ROOT_CERTIFICATE_KEY_VALUE_OF_YOUR_API_ENDPOINT_HERE inside pin-set pin tag with the value of expiration date of this respective certificate.
and then
3. We need to add this network_security_config.xml into our App’s AndroidManifest.xml file inside networkSecurityConfig tag.
and these are the most common ways to implement SSL Pinning.
