Thoughts on Security

An old adage in cryptology is that encrypting data is always easy, but key distribution is always hard. One good example of this is in the Certificate Authority (CA) system; which of course is the system that authenticates websites you visit over HTTPS.

Just a few days ago, Google reported (http://goo.gl/dvqpDN) that yet another wrongfully-issued certificate had been found for Google's domains; this time by an intermediate Certificate Authority of ANSSI, the French Certificate Authority (and part of the French government). This is just the latest example of wrongfully-issued certificates. Previously the DigiNotar CA was compromised and hackers were able to obtain fraudulent certificates for websites they did not own, and TrustWave found itself in a similar position to ANSSI. Amid concerns over espionage; many intelligence agencies are believed to be able to covertly obtain certificates for any site they should want, since there are so many (over 150) certificate authorities trusted by modern browsers, and they are in so many different countries, and it only takes one to get a certificate for any website you should want. Noone even knows how may Intermediate Certificate Authorities have been issued by the primary CA's; intermediate CA's are trusted just like primary CA's, which means there are likely hundreds more CA's out there that could be hacked or secretly ordered to provide fraudulent certificates.

Since each certificate is traced back to only one CA, it is not feasible for users to remove trust in CA's, as they will also lose their ability to trust every site that uses a certificate from that CA. That is why browsers still trust the ANSSI root CA, even after this incident.

Proposals

As a result of these incidents and problems, many different proposals have been made to improve the system:

• Certificate Transparency Google is advocating for their CT proposal. CT has three main goals (quote from http://www.certificate-transparency.org/what-is-ct:
  • Make it impossible (or at least very difficult) for a CA to issue an 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.

  CT creates a system of public certificate logs that can be run by different organizations. It requires browsers to be modified so that each time the browser encounters an SSL certificate, it must obtain cryptographic proof that the certificate has already been added to one or more of its recognized logs; or it must send the certificate to one of those logs and get confirmation. Using crypto, it can validate that as new items are added to the log, this cert has also been added. If a log is misbehaving, it can be detected by the browser or perhaps by an external monitor. Monitors comb through the log looking for wrongly-issued certificates. If a bad certificate is found, existing revocation mechanisms will be used to revoke it.

• Client Certificates Client certificates uses the built-in features of the SSL/TLS suite to authenticate the client. It was covered in Adding Easy SSL Client Authentication To Any Webapp and elsewhere on the web. Client certificates stop these attacks because in order to intercept client-authenticated SSL/TLS sessions, the attacker must also have the client's private key, or another certificate recognized by the server for the client. But client-authentication as normally implemented only trusts certificates issued by the server, not by any outside CA, so any of our attacks would fail. (unless attackers had hacked the server, but if they had hacked the server, they wouldn't need to intercept the SSL, they could take the data after the server decrypted it) The server owner must modify the site to issue or recognize existing client certificates to each of the site's users. The users' browsers will generate and store certificates. This only works on sites with authenticated users; sites you have to sign in to such as email, banking, social networking, etc. But if users do not authenticate, then the information on the site is public. Since the objective is to keep information safe from prying eyes, authenticated users is usually a good assumption.
• DANE DNS Authentication of Named Entities, or DANE, is a proposal based on DNSSEC to eventually replace the CA system. It is based on the simple idea of using the DNS hierarchy to issue SSL certs the same way that domains are managed and resolved; with few root keys and individual organizations in charge. For example, there is one organization for each Top-Level-Domain (TLD); for .com, it's Verisign. Verisign's servers vouch for who owns what .com domain. Since there is only one owner of .com, there is only one organization that could sign the keys for the owners of example.com. DANE also requires browsers be modified to perform DANE lookups, and can only be enforced if everyone implemented it or for a whitelisted set of domains.
• Convergence Convergence (convergence.io) to quote its website: "Rather than employing a traditionally hard-coded list of immutable CAs, Convergence allows you to configure a dynamic set of Notaries which use network perspective to validate your communication." It is designed to stop any of the attacks we have seen by comparing the certificates a client sees with the certificates notaries around the world see. Notaries could also use different criteria to determine what certificates to accept. Convergence requires browser modification, and is currently implemented as a Firefox addon. Since each notary can vouch for any site, and multiple notaries should vouch for most sites, you can remove trust from a notary likely without losing trust in any site you care about.
• TACK TACK (Trust Assertions for Certificate Keys tack.io) to quote its RFC draft: "enables a TLS server to support "pinning" to a self-chosen signing key. A client contacting a pinned host will require the server to present a signature from the signing key over the TLS server's public key." It is designed to stop any of the attacks we have seen by allowing the server owner to inform clients that a separate key, the server owner's key, must be used to validate the server's certificate. It works if the client has visited the server prior to an attack (usually a good assumption).
• Pinning Pinning is a technique to block a site (or notify a client) if the server's certificate has changed or if the server's certificate authority has changed. Most notably, it is implemented in the Firefox "Certificate Patrol" addon. It works if the client has visited the server prior to an attack (usually a good assumption). It has issues with some multiple-server sites, since sometimes companies purchase different certificates for different servers hosting the same site.
• CAA Included since Google included it in their comparison, CAA is merely a mechanism for CA's to verify they are not accidentally issuing a cert for a site that another CA has already issued a cert for. It is the only proposal that doesn't require client or website modification, but it doesn't stop most attacks.
• DNSChain DNSChain is a blockchain-based method to replace issuing DNS names, described here: https://github.com/okTurtles/dnschain Notably, it requires servers to enter their information into a blockchain-based system to track names and certificates, and clients must use a DNSChain gateway/DNS server. Using a blockchain to validate servers relies on a method similar to the method that the bitcoin currency uses to validate transactions, which is reliable unless a powerful adversary could obtain a majority of the resources in the network.

Criteria

Google's CT page compares some proposals, but I thought it did not include all the options, did not do justice to some of the competing proposals, and glossed over some of CT's big issues. I evaluated each proposal according to these criteria:

• The first criteria is in how well each proposal stops different attacks. I first included a reminder that none of these proposals can secure your data if the client or server is compromised. Next is whether the proposals will stop a global attack or an MITM of the server to the internet (possibly executed through DNS hijacking or other attacks) and whether the proposals will stop a targeted attack, which is the most common.*
• Next for CT's sake, I included whether the proposals will detect a global or targeted attack eventually.
• Next is the critical issues of server or client modification required. If client modification is required, then a website owner cannot currently protect his clients with that proposal. If server modification is required, then a user cannot currently protect their interaction with a website with that proposal. If CA modification is required, neither might be able to protect their interaction without the CA cooperating.
• Next is the issue of side channels. If side channels are required, in a typical MITM attack, the attacker can simply block those side channels. Also, as Google points out, side channels fail 1% of the time anyway. Although Convergence requires side channels, since it can rely on any of a number of notaries, it is very unlikely (when not under attack) that all of the notaries would go down at once.
• Next is the issue of instant key change. If a key was compromised or lost and a website operator needs to change the key, can they do so immediately without users getting errors or false attack alarms? This is where pinning fails, and it is also an issue for Convergence and could be for TACK.
• Next is the issue of third party trust. Although DANE and Convergence do require third party trust, their trust models are still much superior to the existing CA trust model, so don't put too much weight on those red blocks.
• Next is the issue of third party infrastructure. This is also not a huge issue, since there is already some third party infrastructure set up for Convergence, DANE, and CT, but implementing DANE is still very difficult since many registrars do not support it, and there needs to be a lot more CT infrastructure and CA buy-in before CT will work as planned.

I put together the below spreadsheet to compare the different proposals, and show where each one breaks down. Some of these were judgment calls, so if you disagree, let me know. You can also view it at this link: http://goo.gl/CkcBaq

Bottom Line

• If you run a website and want to protect your clients without requiring them to change browsers or install different client software, your only option now is client SSL certificates. But it's a really good option.
• If you are a website user and want to protect your browsing, your only options now are pinning and Convergence. Although pinning has a lot of strengths, it has a lot of hassle and false positives which the chart below doesn't do justice to. Convergence is a lot smoother, and although it technically relies on side channels to third parties and may not handle immediate key change, its redundancy ensures those failures or false positives will be rare.
• If you want to create a whole new system from scratch, DNSChain is an all-encompassing system with a number of benefits, DANE seems to make more sense than the existing CA infrastructure, TACK is a nice thing to pin on, and CT has the nice effect of turning every browser into a giant global certificate intrusion detection system, which could have some significant deterrent effects.

* CT does not stop these attacks immediately, since it relies on browsers to report these certificates to log servers, the log servers to eventually publicly display them, monitors to recognize the new cert, server owners to be notified and report the fradulent cert to a CA and then the CA to revoke the cert. In a targeted MITM attack, this will only happen once the attack is over. (Let's suppose as proposed each CA does run a log server; a hacker who takes control of the CA or an intel agency compelling the CA to give them a cert could simply give themselves a log validation and then roll back the log to before they were there. The new cert will not be displayed publicly in the log, the false view of the log with the cert will just be given to the victim, and noone will notice until the attack is over and the victim communicating with the log now realizes the log has changed)

This post has been updated on 30 Sept 2014 with DNSChain info.