A Security Issue with Google Certificate Transparency and Prevention Through CertLedger

Considering CAs as fully trusted parties should be avoided in conventional PKI in order not to cause major security and privacy issues. This is the reason why Google has issued Certificate Transparency (CT) concept in 2013. In addition to this, there have been several PKI models proposed to lower the trust assigned to the CAs. But with different views of the log available for presentation to the victims, all these proposals remain vulnerable to split-world attacks.

The new PKI architecture based on blockchain raised with CertLedger solution eliminates the split — world attacks idealizing the method for certificate/revocation transparency. Moreover, there is no necessity for TLS clients in CertLedger to make certificate validation storing the trusted CA certificates.

In our world of Web based applications such as mailing, e-commerce and banking with highest degree of privacy and security required, SSL/TLS certificates became a standard of authenticity, supporting integrity and confidentiality. However, this approach led the users to place excessive trust to CAs for all conventional PKI systems. Although CAs have the responsibility to issue correct certificates, this doesn’t prevent them from being compromised with fake and valid certificates issued.

In recent years, there have been several examples of the results of placing excessive trust on CAs.

• The Stuxnet malware signed by two compromised CAs caused serious harms to industrial systems in Iran controlling the gas pipelines and power plants.
• Comodo CA hack of March 2011 by an Iran based attacker resulted in issuance of 9 fraudulent certificates.
• Malicious Windows updates or Firefox plugins were distributable after Dutch CA DigiNotar was pawned resulting in fraudulent certificates issued for valuable domains such as *.google.com, *.windowsupdate.com and *.mozilla.com.
• Lenova Superfish has deployed a local CA in its products in 2015. This CA is used to inject ads into the TLS protected web sites. Since the CA’s private keys had been in the computer RAM, they would have been easily used to introspect traffic.

All these incidents and many more simply show how “single point of failure” can be fatal for conventional PKI systems regarding CAs as the keystone.

Till the emerge of Blockchain technology, researchers spent effort to detect fake but valid TLS certificates coming up with various solutions, the most commonly accepted of which is CT (Certificate Transparency) by Google, details of which will be explained a bit more.

Certificate Transparency (CT)

The basic idea behind CT by Google is just providing append-only, publicly auditable logs for all issued TLS certificates with their lifetime shortened, thanks to Merkle — Hash Trees. There are new entities introduced with this concept such as Certificate Logs (CL), Monitors and Auditors.

Certificate issuance process have new steps introduced by CT improving the existing CA infrastructure which can be seen as highlighted below.

• Certificate from CA is purchased by the server operator.
• Server operator is validated by the CA.
• A precertificate is created by the CA returning a signed certificate timestamp (SCT).
• A signed certificate timestamp (SCT) is returned from a log server by CA, where the precertificate is logged.
• SSL certificate is issued by the CA.
• SCT may be included by the SSL certificate.
• SSL certificate is validated by the browser during the TLS handshake.
• SCT provided during the TLS handshake is validated by the browser either through OCSP (Online Certificate Status Protocol) stapling, through a TLS extension or from information embedded in the certificate.
• Browser connects to the server.
• All data is encrypted with the SSL certificate from browser to the server.

As briefly introduced before there are four components for the CT system, 3 of which are newly added to the conventional PKI systems:

• CA
• Certificate Log
• Certificate Monitor and
• Certificate Auditor

The diagram below shows how CT updates the TLS/SSL system of the conventional PKI architecture.

In this figure, CA says the Log Server that he is going to issue a certificate (called precertificate). The Log Server responds with a signed certificate timestamp (SCT), which basically assures to add the certificate to the log. The domain owner (example.com) receives its certificate together with SCT. During a SSL/TLS communication, the domain owner sends both the certificate and the SCT to ensure the existence and the validity of the certificate to the client.

CT Components

CA: Existing publicly trusted CA system is the backbone of CT. SCTs allow browsers to check for evidence of certificate issuance in a public log during the handshake. Proper operation of the CAs and insight on the operation is supported by this evidence.

Certificate Log: Ideally they maintain a record of all SSL certificates issued and they are all

• Append-only: Certificates can only be added to a log and cannot be deleted or modified
• Cryptographically assured: In order to prevent tampering, Merkle Hash Tree is used as a cryptographic mechanism.
• Publicly auditable: A log may be queried by anyone for misused and rogue certificates. Their URLs and public key are publicly advertised by all certificate logs.

Certificate Monitor: Anyone watching the certificate logs for suspicious activity like brand owners or CAs is called a certificate monitor. It is possible to fetch info from the logs using an HTTP GET command. Therefore, each customer has the ability to act as their own log monitoring service.

Certificate Auditor: This is the component checking the logs to verify the consistency with other logs. Auditors can be standalone services or the secondary function of monitors

Following is a brief diagram of how these components integrate.

Problems with CT: MitM In Action

Here comes the main security issue with CT.

• What happens if an adversary gets a fake but valid TLS certificate with the ability controlling the certificate log?

The question above is the basic one, which should be asked while evaluating how CT could satisfy tight authenticity requirements of today. In such a case, it is obvious that such an adversary can perform an impersonation/MitM attack with a fraudulent view of the log provided containing the fake certificate. The adversary can obtain the bogus SCT for the fake TLS certificate from the log. Although the log maintains more than one hash tree with fake SCT; showing different views of the tree to different sets of clients, the adversary can prevent the victims from understanding that the proofs are not generated from the genuine hash tree. This is attack is so called “Split-World Attack”.

So a targeted victim client can be deceived by the adversary controlling the traffic with fake certificate and bogus SCT sent to the client. In such a scenario, it is impossible for the monitors to detect the attack, since they can verify the consistency proofs only from the genuine view of the log as it is the case for the Auditors.

It is worth noting at this point that having sufficiently large number of clients and servers gossiping their STHs (Signed Tree Heads) with each other may be a solution.

In fact, the IETF and Google CT people are already aware of this attack and proposed a mechanism in RFC 6962 for CT states as: “All clients should gossip with each other, exchanging STHs at least; this is all that is required to ensure that they all have a consistent view. The exact mechanism for gossip will be described in a separate document, but it is expected there will be a variety”. Therefore, as also directly implied by “all clients gossiping to each other”. However, this separate document has never existed due to its inscalability. Namely, it is neither practical nor secure to require that devices (e.g., computers, mobile phones) in the world must talk each other.

Solving the regarded security and privacy issues earlier, blockchain technology provides a promising provable prevention. Auditable and monitorable public log of all certificate fingerprints could also still provided by the transparency of data and process on the blockchain.

Decentralizing the trust for PKI infrastructures, CertLedger stands up for better privacy and real authenticity solving the major problems of conventional models even with CT, namely:

• Split-world attacks
• Certificate revocation and validation problems
• Trusted certificate/key store management problems.

Welcome to a new era of certificate transparency…