(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

November 21, 2016 2

Everything You Need to Know About Certificate Transparency

in Industry Lowdown

What Certificate Transparency is and how it makes SSL more secure.

Recently we’ve been covering a lot of news about Certificate Transparency, namely that Google is about to mandate it in October 2017 and that Mozilla has announced it will support it.

So what exactly is Certificate Transparency? Let’s start from the top.

SSL certificates help keep your visitors secure. They provide encryption and server authentication which are crucial to securing communication with your website’s servers. SSL certificates indicate to an end user that they are communicating with the legitimate server hosting that site, and not an imposter.

However, the SSL ecosystem is incredibly complex, and as an industry, we have to ensure strict practices are followed in order to keep things working properly. In the past, there have been deviations from these practices that have threatened to compromise the SSL industry as a whole.

The issue is that SSL has an incredibly complex threat model—which is a description of the possible attacks that a system is vulnerable to. This means that multiple mechanisms are needed to ensure the SSL ecosystem is optimally secure. Certificate Transparency is one of those mechanisms—it attempts to address a specific threat: misissuance.

Misissuance occurs when a Certificate Authority (CA) issues an SSL certificate improperly. This may mean that the CA included incorrect information in the certificate, issued the certificate to someone who did not represent the organization or domain, or was even compromised.

Certificate Transparency (CT) is a mechanism which helps domain owners and industry watch dogs detect misissuance. It is a publically-available log of certificates that have been issued. This log lists all the certificate’s information so that it can be inspected by anyone with an interest. In practice there are multiple logs, which is needed due to the scale of the SSL ecosystem – millions of certificates are issued each year. Each log has to follow defined standards on what and how it stores the certificates.

Organizations and people can then search the logs (or set up automatic notifications) to see what SSL certificates exist for the sites they own.  This means that CT is not “automatic” in the traditional sense. Even if all SSL certificates were immediately logged after issuance, the domain owner would still need to be looking for certificates in the logs to spot any that may be misissued.

Searching CT Logs

Now, when I say someone needs to search the logs, I don’t mean they have to go line by line looking through everything. There are multiple services that make it easy for an organization to do this. Websites like crt.sh support advanced searching criteria so you can look at only what is relevant to you. Other services allow you to set up notifications, so you can be alerted as soon as a new potential match occurs. Most of these tools search all the CT logs that exist.

It’s important to understand that Certificate Transparency only allows detection of misissued certificates after the fact. CT cannot prevent misissuance. It also cannot work autonomously. The legitimate domain holder needs to be looking at the log information in order to know if there are any misissued certificates out there.

It may also be difficult to know if misissuance is occurring if there is a disorganized certificate provisioning system in place. For instance, a large university which delegates sub-domains to different departments or projects may have a hard time knowing if an issued certificate is legitimate or not if they do not have well-defined practices.

Before CT existed, there was still the possibility that a domain owner could become aware of misissuance. But there would have to be evidence of abuse or other obvious signs, which could take weeks – or in the high-profile compromise of the CA DigiNotar, it took a month for their missuance to be detected. This means there was an entire month that users could have been phished, snooped on, or otherwise attacked by those misissued certificates. Attentive organizations like Google and Facebook have used CT to minimize that detection window to just a few hours.

But I must stress – you need to be looking in the logs for CT to be of any use for you.

How do Certificates Get Logged?

SSL Certificates are primarily added to logs in two ways. When a certificate is issued, the issuing CA has the choice to log it. This is the best method because it means certificates are being logged by the source. In some situations CAs are required to log – Google requires all EV SSL Certificates to be logged to receive the green address bar. And, as we mentioned earler, in October 2017 Google will require all SSL certificates to be logged. But, for the time being, logging is still optional for the majority of issued certificates. A few CAs log all the certificates they issue – Symantec, StartSSL, and Let’s Encrypt – the rest only log certificates when required.

The other primary source of logged certificates come from “web crawlers.” When Google’s search engine indexes a page, it also logs any SSL certificates it finds. Usually certificates are seen and logged by Google within a few days, however Google cannot automatically see every certificate. If a certificate is not used on a public network, or it’s used on a sub-domain that is not indexed, then those certificates remain unlogged and unknown.

How CT improves security

One of the unfortunate downsides of the CA system is the ability for one irresponsible CA to negatively impact the entire ecosystem.

A CA is allowed to issue a certificate for any existing website (this is a generalization, but its accurate for the most part), so even an organization with tight policies on certificate issuance can still be negatively affected. This was the case with the breach of the Dutch CA, DigitNotar. In 2011, DigiNotar was hacked and the attacker had the ability to issue certificates for any domain he wanted without proper authorization. The attacker issued certificates for various Google services. As an organization, Google has very strong security practices. Google is always on the cutting edge of SSL/TLS practices – it created Certificate Transparency – but that could not protect it from DigiNotar.

Computers that support the SSL/TLS protocol have a “root store” (or “trust store”) which lists the CAs that they trust. From the computer’s perspective, this root store tells them what CAs are allowed to issue certificates. Because computers can’t think for themselves they are not able to recognize misissuance on their own. There are other security mechanisms that can help computers with this. But if a certificate has been issued by a root that is trusted, by default most computers will automatically trust it.

You can see how that could cause catastrophic consequences for the entire industry. One large enough mis-issuance, were it to affect a high-profile website and victimize enough internet users—could even potentially undermine SSL as we know it.

Certificate Transparency can help mitigate this problem.

That’s why it’s so exciting to see companies like Google and Mozilla pushing the initiative forward to the point where CT becoming mandatory for all CAs is no longer a matter of if—but when.

• #Certificate Authorities
• #Certificate Transparency
• #Google
• #Mozilla
• #SSL
• #TLS