Welcome back! In the first part of this series, we explored the fundamentals of SSL pinning covering how it strengthens application security by ensuring connections are made only with trusted certificates. However we wrapped up with some challenges particularly in managing certificate expiry and ensuring a seamless user experience.
In this second part, we’ll address these shortcomings by exploring alternative approaches and best practices to overcome them. Let’s dive in!

Mitigating Certificate Expiry

If you wanna utilize the benefits of SSL pinning but still keep the user experience in mind and minimize the need for updating the app, there are a couple of options you can try.

Dynamic SSL Pinning:

A dynamic pin management system can be implemented by fetching and updating pins from a secure, trusted source, such as a backend API. This API communicates with a server that houses the generated certificates. Whenever a certificate expires or requires replacement, it is seamlessly updated on the server via the backend. These changes are automatically reflected on the client side, eliminating the need for user-facing updates or app re-publishing. This approach ensures both security and convenience while maintaining a streamlined user experience.

However this leaves us with a very important question, isn’t there a risk of a Man in the Middle attack when the mobile side communicates with that API? The answer would be yes indeed it’s possible. Leaving this option open for exploitation.

Backward compatibility key rotation:

Another simpler approach would be to maintain multiple pins: primary and backup (e.g., current and next public key).

You can create multiple certificates in advance with a future validity start date and pin those certificates or their keys prompting the client side to verify a specific set or array of certificates, this could give you more years to your pinning.

Mutual TLS (mTLS)

We then started thinking in a different way: the way it goes is the attacker impersonates the server when communicating with the client and impersonates the client when communicating with the server. So far, our focus has been on preventing the MITM from communicating with the client as if it were the server. but can we prevent it from communicating with the server as if it were the client?

After some research, we discovered mutual TLS (mTLS), which adds an extra layer of security by requiring mutual authentication; both the server and the client must present valid certificates.

At first, it may seem like this solves the problem, as the MITM would no longer be able to carry out the attack, however, mTLS may not be practical for mobile applications, as it requires every client to possess a unique certificate.

Managing and securely distributing these certificates at scale for millions of mobile users introduces significant logistical and security challenges. This makes SSL pinning a more efficient choice for securing mobile applications in most cases.

Certificate Transparency

Next, we explored another approach, Certificate Transparency (CT), which is supported by major security organizations in the tech industry.

The core idea of Certificate Transparency is to log all issued certificates in a publicly accessible, append-only log. These logs are maintained by trusted entities, ensuring transparency and auditability.

This means that if someone tries to fake a certificate for your domain, you can detect it by reviewing the logs, which contain both valid and invalid certificates. By actively monitoring these logs through tools or services like crt.sh or CertSpotter, you can quickly identify unauthorized certificates before they can be used maliciously. Once detected, you can initiate the revocation process with the Certificate Authority (CA) that issued the fraudulent certificate.

However, this approach has multiple drawbacks:

• It requires significant manual effort—monitoring, alerting, and revoking certificates.

• It doesn’t prevent MITM attacks in real time.

This is where the Signed Certificate Timestamp (SCT) comes in. It’s a cryptographic timestamp issued by the CA that contains the hash of the certificate, timestamp, and a signature from the CT logs server. The SCT then serves as proof that a certificate has been logged in a public CT log.

During the TLS handshake, the client performs the several following checks to validate the SCT:

• The certificate has an SCT attached, otherwise rejects the certificate because it has not been logged in a CT log.

• The timestamp of the SCT is valid and corresponds to the time the certificate was actually logged in the CT log.

• The log is a valid and recognized CT log by validating the log's certificate or public key.

• The certificate being presented matches the one that was logged.

So how should you apply CT to effectively avoid MITM attacks?

Ensure Your CA supports CT 🫨:

• Your Certificate Authority (CA) must support Certificate Transparency (CT) and log the certificates it issues for your domain in public CT logs.

• This typically happens automatically with most modern CAs that support CT, but it’s good to confirm this with your provider.

Enforce CT Compliance on the Client Side:

• Clients (like browsers or mobile apps) need to enforce CT compliance by validating that certificates include a Signed Certificate Timestamp (SCT) and that the certificate is logged in a public CT log.

• Most modern browsers like Chrome already do this automatically, but if you're developing apps (like mobile apps), you need to implement CT compliance manually (e.g., using OkHttp for Android).

• This ensures that only certificates logged in CT logs are accepted, blocking fraudulent certificates and preventing MITM attacks.

Throughout this series, we've covered various strategies to enhance your application's security. Each approach offers unique benefits, and the decision ultimately depends on what works best with your application's requirements.
The tools and techniques are here—now it's up to you to decide what works best for your situation. Security is all about finding the right balance, and we hope this journey has equipped you with the insights to do just that.

Thank you for following along—see you in our next article! 👋🏼