How to Perform SSL Pinning in iOS Apps

The moment people step out of their homes, they go on a quest for open wi-fi networks. Whether they are waiting at the airport or completing their college project at a cafe, the prime agenda is to find an open wi-fi connection. 

Scaredly, the hackers are also on the same quest. They too wait for the users to initiate a connection request on the open network before they put their phishing brains into work and deprive them of their sensitive data or worse, money in their bank account. 

While HTTPS is effective to some extent, it is an SSL protocol which is known to make users safe  by being unbreakable and largely secure. But Man-In-The-Middle (MITM) attack has found ways to breach this too. 

This is where SSL Pinning comes into the picture as one of the mobile app security best practices. Talking specifically about platforms, it is the ideal iphone app security solution that does an amazing job solving the issue. 

In this article, we are going to look into the process of incorporating SSL Pinning in iOS apps for preventing these Man In The Middle attacks. A process that is an active part of the OWASP mobile security testing practice. 

1. What is SSL Pinning?
2. Why Do You Need SSL Pinning in iOS?
3. Types of SSL Certificates Pinning Implementation
4. How to Implement SSL Pinning in your iOS App
5. Common Issues Associated With SSL Pinning Implementation & How to Solve Them
6. FAQs About SSL Pinning in iOS Applications

What is SSL Pinning?

When a mobile app communicates with a server, it uses SSL pinning technique for protecting the transmitted data against tampering and eavesdropping. On a default mode, the SSL implementations used in the apps trust any server having certificates trusted by an operating system’s trust store. 

With SSL pinning, the app is devised to reject every but one or limited predefined certificates. When the app connects with a server, it compares the certificate with the pinned certificate. Only when there is a match, the server is trusted and SSL connection gets established. This is what makes SSL Pinning one of the best iOS app security tips that developers follow. 

Why Do You Need SSL Pinning in iOS?

The task of setting and maintaining the SSL session is given to a system library. It means that the app which tries to establish a connection doesn’t determine which certificate must be trusted and which shouldn’t be. 

A hacker who is able to generate a self-signed certificate and add it in the operating system’s trust store is able to set up a MITM attack against apps that use a SSL. This allows them to do things that works opposite of the iOS application security tips:

• Read and modify all the SSL sessions and use the access for reverse engineering the app protocol or for extracting the API keys from request – a classic example of mobile app frauds. 
• They can also hinder the SSL sessions through tricking users into installing trusted CA through malicious web pages. The root CAs which are trusted by the devices can also get compromised and can be used for generating certificates. 

By lowering the number of trusted iOS SSL certificates, the apps are protected from such remote attacks. It also helps eliminate the occurrence of reverse engineering – one of the biggest roadblocks in iOS app security testing. 

Types of SSL Certificates Pinning Implementation 

The implementation of SSL pinning gives you two options – 

• Pin the certificate – you can download the server’s certificate and bundle them in the app. At the runtime, the app compares the server certificate to ones that you have embedded. 
• Pin the public key – you can retrieve the public key of certificate in the code as string. At the runtime, the application compared the certificate’s public key to one which is hard-coded in the code. 

Making a choice from between the two SSL pinning methods is dependent on your server configuration and individual needs. When you choose the first option, you will have to upload the app when the server changes its certificate or it would stop working. When choosing the second option, you might violate the key rotation policy for the public key won’t change. 

Let’s now look into how to make these methods the iOS app security best practices. 

*Note: Both the examples that you are going to read next follow the process of iOS certificate pinning with Swift 

How to Implement SSL Pinning in your iOS App

1.  NSURLSession

In case of NSURLSession, the primary method for handling SSL pinning is URLSession:didReceiveChallenge:completionHandler:delegate. Developers will have to set the class to conform URLSessionDelegate and paste this function to the class:

The function would “requests credentials from the delegate in response to an authentication request from the remote server.” The developers will then compare certificates from the server with one saved in the app bundle. If the two certificates are found identical, authentication will let it pass and the client will be able to connect to the server.

2.  Alamofire Certificate Pinning

Alamofire is one of the most famous libraries for HTTP networking in Swift language. It comes with the built-in functionality for SSL pinning in iOS Swift and is extremely easy to use. Here’s how to secure an iOS app with Alamofire certificate pinning.

Common Issues Associated With SSL Pinning Implementation & How to Solve Them 

The Quality Assurance Experts at Appinventiv, we regularly test our mobile apps for security vulnerabilities, including full network penetration. But there are many app testing agencies that don’t focus on these with the same enthusiasm. And can seem reluctant when implementing this particular iOS security framework in their apps.

Here are some of the prevalent reasons behind this –

• One of the biggest disadvantage of SSL pinning in iOS is its implementation. The process is complex and it can force the developers to write the code again and complicate the app builds. 
• Pinning certificates which are bound to change regularly can force the developers to update the app binary everytime certificate changes. 
• Multiple efforts have to be taken to safeguard the ways to bypass iOS SSL verification.

Noting the repercussions that the stage’s absence can bring, here is how some common pitfalls are avoided by a reliable iPhone app development company. 

Testing the pin

Unlike regular app testing where you test whether or not everything works, the method for the SSL pinning test is that you’ll have to check whether something fails. You will have to focus on testing that the app cancels potentially compromised connections. If the app enables communication with a single endpoint, testing will be as simple as making the GET request to arbitrary state. Ideally, in this case, the app must cancel the connection and request should fail. 

Handling certificate change

Renewing a domain certificate retains the public/private key pair, but this is not always the case. But if you plan the update cycle rightly, you will be able to avoid the downtime for end users. 

Before the certificate is made active on the website, you must pin it in the app, in addition to the presently active certificate and then release an update. When we follow this step at Appinventiv to make secure iOS app we perform a quick test with the new certificate temporarily and test the app with both the certificates pinned. 

FAQs About SSL Pinning in iOS Applications

1.  Where to store sensitive data in iOS app?

The app’s sensitive data should always be stored in iCloud or Keychain in iOS or even in the database after proper encryption.

2.  How does SSL work?

SSL Pinning is one of the most common iOS app security tips. But in order to understand what it means, you will first have to know how SSL works. 

• A browser attempts to connect with a website which is secured with a SSL. The browser then requests the web server to identify itself.
• Web server then sends the browser its SSL certificate copy.
• The browser checks if the SSL certificate must be trusted. If it can be, a message is sent to the web server.
• Web server then sends back an acknowledgement to begin the SSL encrypted session.
• The encrypted data is then finally shared between the browser and web server.