This week Google learned of another batch of fraudulently issued certificates for several of their domains. At the end of the post they made a renewed call for Certificate Transparency. In this post, we’ll use the acronym CT to refer to Google’s implementation of the general concept of certificate transparency, and we’ll explore other technologies that also provide it.

Fraudulent SSL/TLS certificates are used to perform man-in-the-middle attacks (MITM). While widespread adoption of CT would not prevent attacks from happening (as we discuss below), it can help with their discovery. We noticed that there’s still misunderstanding about this aspect of CT, and so to help clear up some of the confusion surrounding CT we’ve decided to revisit the topic.

How might Google’s CT effort help improve today’s situation? CT incentivizes Certificate Authorities (CAs) to publicly document their SSL certificate issuance. In the current system, SSL certificates are issued mostly in private, and therefore it’s extremely difficult to discover whether someone issued a certificate they shouldn’t have. Discovery is possible even without CT (Google’s blog post is a demonstration of that), but it requires the use of pinning mechanisms that cannot be generally applied for arbitrary websites.

So what exactly is “certificate transparency”, and are there other approaches that do as good (or better) of a job at achieving them?

We can discern the properties of certificate transparency by looking at the goals CT sets out to achieve:

Certificate Transparency aims to remedy these certificate-based threats by making the issuance and existence of SSL certificates open to scrutiny by domain owners, CAs, and domain users. Specifically, Certificate Transparency has three main goals:
  • Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
  • Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
  • Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.
Let's see how CT compares to blockchain-based approaches.

 

"Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain."

Google's Certificate Transparency

From our previous analysis we know CT does not make it impossible to hide certificate issuance:

  • CA/log combos can use hidden Merkle trees to hide certificate issuance, even in a world where CT is mandatory for all CAs. The CT spec allows one SCT to accompany a certificate, making this attack feasible. If clients require SCTs from more than one log, the likelihood of this attack can be reduced.
  • Domain owners either have to put their trust in the CA they've chosen to correctly monitor all logs 24/7 for fraudulent issuance, or they have to monitor all logs themselves (something they are extremely unlikely to do). EDIT March 27, 2015: See followup article: Certificate Transparency’s improved gossip protocols show promise
To summarize: it might be possible for CAs to issue certificates completely undetected, and in the case of normal operation, certificates, while technically visible, are difficult for ordinary domain owners to monitor. We can say CT might achieve this goal if all CAs participate in the system.

EDIT March 27, 2015: CT’s recently updated gossip protocols are a significant improvement in this area, please see our followup blog post.

Blockchain certificate transparency

Short of the fundamentals (broken cryptography or private key compromise), no entity can issue a certificate for a blockchain domain that does not belong to them, because they do not have the private key.

 

"Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued."

Google's Certificate Transparency

As discussed above, CT allows hidden issuance and makes it difficult for most website owners to monitor all logs for mis-issuance. However, CT does provide an auditing and monitoring system that could alert others to the issuance of a fraudulent certificate by a CA, so in that sense they achieve this goal.

EDIT March 27, 2015: CT’s recently updated gossip protocols are a significant improvement in this area, please see our followup blog post.

Blockchain certificate transparency

CT is a detection mechanism, not a prevention mechanism, so it operates post-fail. Blockchains fundamentally solve this problem earlier: detection becomes irrelevant when the system can provide provable prevention. In addition to preventing mis-issuance from happening, they also provide a public log of all certificate fingerprints that is auditable and monitorable.

 

"Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued."

Google's Certificate Transparency

The bar for “as much as possible” has been set by blockchain technology at the prevention of fraudulent certificate issuance. Even if Google were to succeed in getting every single CA to adopt CT, it would not prevent fraudulent certificates from being used to perform MITM attacks.

Fundamental to the design of X.509 is the concept that third-parties are explicitly permitted to issue certificates on behalf of the real owners of websites. This does not change when CT is adopted, and therefore CAs have no way to know whether a certificate actually is valid. The best they can do in a CT world is publicly document the issuance and wait for the real owners to take reactive steps to discover mis-issuance and then do something about it. Attacks can be simple (identical to today’s attacks), or complicated (in an attempt to conceal issuance). See our previous analysis of CT for details.

Therefore, CT fails to meet this goal because it is an attempt at detection, not prevention.

Blockchain certificate transparency

Protecting users from MITM attacks (what this goal is referring to), is not so much about transparency as it is about proper ownership enforcement. Because blockchains provide cryptographic proof of ownership they prevent mis-issuance from happening and therefore “protect users (as much as possible)“.

 

 

How does DNSChain fit into this?

DNSChain provides a way to securely access blockchain data without having to run a full blockchain node on end-user devices. Thererfore, a DNSChain server could itself be used to perform MITM attacks on its clients.

There are now three known mechanisms to prevent such attacks (best used together):

  1. Use a DNSChain server that you have reason to trust. Unlike today's system, users are not forced to trust anyone, they can choose.
  2. Query more than one DNSChain server. Even querying two independent DNSChain servers drastically reduces the likelihood of being attacked. The only way for an attack to succeed would be for the two servers to collude, and even then, this can be mitigated or prevented by:
  3. Use Proof-of-Transition (PoT). PoT is a simple but powerful idea that Dionysis Zindros came up with (which we plan to elaborate on in future work). Briefly: clients store the public key fingerprints of the blockchain transaction that corresponds to a domain. These correspond to the public key that was used to update the blockchain entry. When a new SSL/TLS cert is seen, require DNSChain to provide proof in the form of the transaction(s) that were used to update the blockchain entry. This mechanism can prevent initially-honest servers from cooking the books later on by verifying the transaction(s) were signed by the original public key.
Emin Gün Sirer observed:
The core idea is that it is impossible to use [blockchains] without leaving a permanent, public record, and therefore it is transparent by construction. In contrast, CT techniques are by definition limited in scope to those parts of the network that are monitorable and monitored.
Finally, let's take a moment to address a frequently raised concern with blockchains, which is, how to handle a lost or compromised blockchain private key? For this, there are several techniques, which can be used alone or in tandem:
    • Splitting keys in n-of-m schemes (multisig, shamir's secret sharing, threshold signatures) make it possible to recover from key loss. Lose your private key? Client software can make it possible for others to help by combining shards of the key (perhaps from close friends or trusted third parties).
    • Backups (digital or physical).
    • GPG-style revocation (requires blockchain support). Blockstore is exploring this.
    • Last, but not least, you always have the option of entrusting ownership of your keys to someone else (a trusted third party). This was, after all, the only option previously available.
 

Conclusion

We think it's important to note that not only do blockchains already provide certificate transparency, they do a much better job of it.

Acknowledgements

Thanks to Andrea Devers, Brian Hoffman, Dionysis Zindros, Emin Gün Sirer, Ethan Heilman, Geoffrey Thomas, and Matthew Hodgson for proof reading this post. Special thanks to Dionysis for combing through, replacing subjective statements with objective ones, and improving both readability and accuracy.

For updates on our work, follow @okTurtles and @DNSChain on twitter.

Donating = Loving!
You can empower our work by donating!

Comments