Mobile HTTP SSL PINNING: Decoding the untold
HTTPS is a secure way of communicating with servers. This standard has been accepted for a long time and all was fine for around a decade. With the advancement of the technology and techniques of hacking traditional ways of establishing secure SSL connection no longer suffices the need for today’s security demand. This need gave birth to SSL pinning. SSL pinning is gaining popularity and is been widely adopted in mobile applications and lately even browsers are supporting pinning for web applications.
To decode the purpose of SSL pinning we need to first get 2 concepts clear.
- SSL certificate validation during handshake.
- MITM attack
SSL certificate validation during handshake.
From the handshake, the most important step is step 2. Here application verifies if the certificate provided by the server is it valid or not with the help of root CA’s already present in the trust store. This validation is done by confirming if the certificate is digitally signed with the help of one the root CA public key present already in the trust store. Now let’s try to understand what happens with this validation in place if someone tries to intercept the traffic. This leads to a MITM attack.
MITM attack
Let’s understand the flow of this attack and later we will see how SSL certification validation prevents MITM attack.
Assumption: A genuine user is trying to access xyz.com which is a valid website having a valid SSL certificate issued by one of the CA.
Step1: A hacker who is on the same LAN as that of a genuine user intercepts the SSL handshake.
Step 2: The hacker now will act as a genuine user to xyz.com by initiating his SSL connection.
Step 3: Hacker receives the certificate from xyz.com during the handshake process.
Step 4: Hacker instead of forwarding the xyz.com certificate to genuine user will provide his certificate to the genuine user.
Step 5: Certificate validation happens on the client-side.
Step 6: Hacker starts decrypting all the network traffic and starts viewing it.
In Step 4 a question arises why did the hacker issue his certificate?
The reason being he has the private key only to the corresponding certificate he has issued to the genuine user. Hence hackers will be able to decrypt the SSL traffic. If the hacker had passed on the same certificate issued by xyz.com then the hacker can not decrypt the traffic the reason being hacker does not have a private key corresponding to the xyz.com certificate. This is available only with xyz.com.
Now that we know how MITM happens. Let’s see, does this attack work in the real world? The flow that I have described above will fail in real-time. Because the digital signature of the certificate is verified on the client-side. Thus protecting the user from accepting an invalid certificate and becoming a victim of MITM. Usually whenever applications encounter invalid certificates then the application itself stops handshake or asks for user consent to proceed.
Hurray !!! so we are secure and SSL handshake takes care if my connection is secure and protects me from MITM.
Wait did we consider the scenario where one of the root CA is compromised or if the hacker has been able to push his own CA into your client-side trust store? :(
The above question leads us to 2 ways by which MITM can be achieved:
Case 1: hacker has compromised a genuine root CA (That means the hacker owns the private key of CA which is used to sign a certificate)
Since the hacker owns a valid root CA private key, he can start generating his valid certificate for any domain of his choice. Hence in step 4 of the MITM certificate issued to the client-side will be valid. Thus, leading to a successful MITM.
Here since already existing root CA is compromised by a hacker, he can perform MITM on any user.
Case 2: Hacker has pushed his own CA on to client-side trust store
Since the hacker’s own CA certificate is pushed to the trust store of the client-side, he can start generating his valid certificate for any domain of his choice. Hence in step 4 of the MITM certificate issued to the client-side will be valid. Thus, leading to a successful MITM.
Here since the hacker’s root CA is pushed into the client-side trust store MITM is limited only to that client where the hacker’s root CA is pushed.
The above 2 cases can be summarized in the below diagram:
Is there a common fix for both Case1 and Case 2?
This is where the SSL pinning concept comes into the picture. SSL pinning adds another step into SSL verification preventing MITM.
What is SSL pinning?
SSL pinning implies pinning (or hardcoding) the certificate-related information on the client-side to verify if the certificate is valid. Do not confuse this with digital signature verification of certificate both are two different concepts. As I explain further concepts will become clearer.
The list of certificate-related information that can be pinned are:
- Server certificate itself
- Hash of certificate
- Public key present in the certificate
- Hash of the public key
The flow of the SSL pinning verification is as below:
As it can be seen that along with certificate verification if it is valid or not by cross-checking the digital signature. There is one more verification step involved. In this step, the application verifies that if already pinned information of server certificate matches with the certificate information issued during SSL handshake. This is all that SSL pinning means.
The question that arises now is, how does SSL pinning prevent Case 1 and Case 2 of MITM described earlier?
In step 5 of MITM, if we notice the hacker has to issue his certificate which could be a valid one signed from a valid CA. In this case, signature verification will pass, however, the pinned information will be that of the server certificate and it will not match with the certificate issued by a hacker. Thus, preventing MITM in both cases.
Concluding we have understood the problem because of which SSL pinning is being used, what is SSL pinning? and how it is achieved?. Still, I haven’t provided information on how pinning is implemented, which is the best way of pinning, any drawbacks with pinning, and how we can overcome SSL pinning for pen-testing. Stay tuned for upcoming blogs where I will explain all these interesting concepts.
References:
https://developer.android.com/training/articles/security-ssl
