Certificate Transparency has been a popular term recently. Despite Google's hard effort on pushing every CA to adopt Certificate Transparency, the implications and technical details behind those two words are sometimes unclear. Hence, I am presenting this series of posts detailing the problem it is attempting to solve, how it functions and last but not least, how you as a site owner can take advantage of this new initiative.

The old days

When Internet was first designed, it lacked security features in general. The Internet was much smaller in terms of size and to access it you need to be running dedicated cable between limited number of exchange points. In the 1970s, public key cryptography was something practically unheard of, computer also lacks the processing power for complicated encryption operations. The Internet stayed in this way for many, many years.

RSA to the rescue

When Ron Rivest, Adi Shamir, and Leonard Adleman first published the RSA algorithm, it was difficult to imagine how groundbreaking and revolutionary it was. For the first time, people were able to establish a trust system among computers, and RSA was and still is one of the most important algorithm out there that keeps our online activity secure.

Image source: http://gonitsora.com/rsa-elegant-code/

Certificate Authorities

RSA solved a very important problem - knowing you are taking with the party you think you are talking with over an untrusted network. However, RSA itself does not establishes the identity of the other host. Anyone can claim to be the owner of idndx.com, but browsers need not to trust any claim unless they are verified by certain trustworthy third party, also known as Certificate Authorities (CAs).

So how does CAs knows you are actually who you are? Usually a CA will require certain verifications that it believes only the party controlling the domain can perform, such as adding a DNS record, serving a specific file on a particular URL and etc. Once the CA is happy about what you have prooved, it will issue a certificate and sign your private keys so that clients can put a name to the public key distributed by you. (Extended Validation certificates are essentially doing the same thing besides they dig deeper and asserts more information about the certificate owner)

Is that enough?

The above system seemed to be pretty flawless for a long time as we trust CAs are responsible parties that will not issue certificates without the domain owner's consensus. This problem seemed to became increasingly problematic, just look at those reports:

1. DigiNotar was a Dutch certificate authority owned by VASCO Data Security International.[1] On September 3, 2011, after it had become clear that a security breach had resulted in the fraudulent issuing of certificates, the Dutch government took over operational management of DigiNotar's systems. (https://en.wikipedia.org/wiki/DigiNotar)
2. On Friday, March 20th, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by an intermediate certificate authority apparently held by a company called MCS Holdings. This intermediate certificate was issued by CNNIC. (https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html)

A quick dig revealed that the OS I am using, Mac OS X (10.11.4) has 178 trusted root certificates and theoretically every single one of them could be the next DigiNotar. Despite CAs always has to went through rigorous security audits, sometimes by the time site owners has noticed something went wrong, it might already been too date.

And even if every CAs out there are hacker-proof, we still want to answer questions such as "are there any TLS certificate being issued out for my domain" after a DNS server compromise.

Certificate Transparency to the rescue

Certificate Transparency is a project started by Google after observing the increasing number of CA related incidents in recent years. Certificate Transparency does not prevents CA from issuing rogue certificates, but it will makes the process of detecting those rogue certificates much easier.

So how does Certificate Transparency achieves this?

Certificate Transparency introduced an extra layer of verification for certificates. Previously, a certificate is considered as trusted as long as it contains a valid signature from a trusted CA. With the addition of Certificate Transparency, that signature itself won't be enough and the server also has to prove that the certificate is publicly auditable before it can be trusted.

The word "publicly auditable" might seems to be confusing at first, but it is the most important part of the whole Certificate Transparency proposal. In order to achieve this, multiple Log Servers has been setted up to keep track of every single certificates ever issued by any CA. Log Servers can be run by anyone and need not to be trustworthy (we will explain later why this works). Now, whenever the client is being presented with a certificate, it verifies to make sure that certificate has been logged into at least one of the log server and consider the certificate not trusted if not.

The idea behind this design is to force all CAs out there to submit their certificate to one of the Log Servers before issuing them. Submitting a certificate to a log server does not stops CA from issuing rogue certificates but it makes the detection of such certificates much easier as log servers are publicly searchable by everyone in the world.

If you are interested in knowing who is running the log servers out there, you may check out a simple tool I made called Certificate Transparency Observatory. I will also write more posts in the future to explain how log server operates and why does this system works from a technical perspective so stay tuned!