Certificate Transparency

Securing your SSL connections

If you are planning to offer a service on your site, one of the key aspects that should be considered on the design phase of it is security: You’ll need to manage your customer data, which most of the times will be sensitive data, like payment data, addresses... This statement which you could think it is obvious, it’s often overlooked during this phase as most people think that security comes by default. That is a very BIG mistake that could lead to data loss, revenue loss, legal issues and it could also hurt your company reputation very badly.

Data in transit vs data at rest

So, talking about data, we can categorize our data in two:

• Data at rest: Data that is stored in your databases, data warehouses, etc.
• Data in transit: Data which is traversing a network, being processed by a device, etc.

Data at rest should be easier to deal with, as most cloud providers offer a lot of different services to make sure that your data remains safe. If for some reason your workload is still on-premises, there are also some easy strategies that you can apply to make sure that your data is stored in a safe manner.

However, in today’s article we are going to focus on data in transit. This kind of data is more difficult to protect, as usually goes through networks and devices on which we don’t have direct control and can be managed by a malicious attacker, also know as an adversary.

SSL, TLS… What do they mean?

Probably you heard or you have seen these two before reading this article. Both are cryptographic protocols that are designed to provide communications security over a network. Secure Sockets Layer (SSL) is the old one here, originally designed by Netscape in 1994 (very long time ago!) is already deprecated in favor of TLS as it has a lot of well-known vulnerabilities that can be used to steal your data.

Transport Layer Security (TLS) was initially introduced in 1999 as an evolution of SSL to fix all the security issues that SSL had at that point. Old versions of TLS also have some vulnerabilities, but new ones are widely used today for securing connections. You can use it to secure email, VoiP, but the most publicly visible is its use as the security layer on top of HTTP (HTTPS)

The intention of this post is not to give a masterclass on these two protocols, but show how you can protect against one of the most common attacks to them, Man in the middle.

Man in the middle attack

Without entering too much into detail, what you must know is that when you’re visiting a page over HTTPS, a secure connection is established between you and the site using one of the above protocols. The site uses a certificate to identify itself, then the client extracts the public key of the certificate, which will be used for creating a shared secret for encrypting the communications between your client and the site.

This is a very high overview of what happens when connecting to a site using HTTPS. If you’re connecting from your place, you shouldn’t have any issues. However, there’s a risk in a public network: It’s possible for an adversary to try to route all the traffic through a device controlled by them, presenting you a fake certificate as you can see on the diagram:

Man in the middle example

Certificates must be issued by a Certificate Authority (CA), which is a trusted 3rd party which takes care of issuing / revoking certificates. Based on that, most modern browsers should be able to identify a rogue certificate and they will warn you that something odd is happening with the site that you want to visit. Chrome for example will show you a very scary red page telling you about this, but things are a little bit different on a mobile app, and you could not be aware of what is happening. That’s what happened a few years ago affecting some banking apps and as you can imagine, you’re not going to be happy if someone steals your money from your bank.

Certificate pinning

So, how we can prevent these situations? A few years ago (2011), certificate pinning appeared to address this problem. When you are pinning the certificate, you’re instructing your device to trust ONLY that specific certificate, no matter what happens. And that worked fine, for a while at least. Then we began to realize that the risk is much higher than the reward. A quick example: if you needed to replace the certificate for whatever reason, you would need to release a new version of your app, forcing all your users to upgrade to the new one only because of that, also potentially with downtime until all users are on the new version. The same can apply to IoT devices that surround us every day, like TVs, fridge and the problem with them is that sometimes you’re unable to upgrade them.

Certificate transparency

So, we’re back to the square one and we still need to protect our customer data. Luckily, we can solve that issue with certificate transparency.

Certificate transparency was started by Google as a response to the 2011 attack on DigiNotar and other Certificate Authorities. An unknown attacker was able to compromise these CA’s, and to issue rogue certificates for numerous domains. Over 500 fake certificates were detected and used for man-in-the-middle attacks on traffic from Iran.

Certificate transparency follows a different approach than certificate pinning which relies on specifying which certificate do you want to trust. When a new certificate is issued by a CA, signed certificate timestamp is added into the certificate and also uploaded to a public distributed network of log servers. These servers use Merkle trees, making these logs publicly verifiable, append-only, and tamper-proof. Having these logs in place, makes trivial to check if the certificate that the server is providing is the real deal or it’s a fake one.

Companies like Google or Apple are adding policies to make Certificate transparency mandatory. In Chrome it is mandatory since 2018. The same applies for Apple which enforces stricter policies depending on the expiration date of the certificate.

Certificate transparency info for medium.com as displayed by Chrome browser

Certificate transparency on mobile apps

Implementing certificate transparency in your mobile apps is also quite easy. On iOS, starting at iOS 10, there’s a new flag that enables you to require Certificate transparency.

On Android, folks from Babylon health created a library that makes it easier to integrate certificate transparency in your projects. An example for using certificate transparency with OkHttp, a well-known library is the following one:

val interceptor = certificateTransparencyInterceptor {
    // Enable for the provided hosts
    +"*.foo.com"

    // Exclude specific hosts
    -"*.bar.com"
}

val client = OkHttpClient.Builder().apply {
    addNetworkInterceptor(interceptor)
}.build()

All credits to Babylon health team who created the library. If you want more examples, check their project in GitHub

Wrapping up

As I said at the beginning, don’t take the security in your projects for granted. I hope that you find this post useful and helpful for improving the security in your mobile applications.

Regarding certificate transparency, if you want to know more technical details about how it’s implemented, I recommend you go to the official site here.