A Comparison of HTTPS Reforms

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.


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.


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.

, , , , , , , , , , , , ,

  1. #1 by Greg Slepak on February 19, 2015 - 12:28 am

    Hey Matt!

    Great comprehensive post! So, here’s that belated reply I promised you. So sorry it has taken me months to send it!

    I’m just going to go through your entire document and point out things that I notice:

    Certificate Transparency

    If a log is misbehaving, it can be detected by the browser or perhaps by an external monitor.

    It may be worth mentioning that it depends on the sort of misbehavior. Most misbehavior will not be detected by browsers:

    > “I’m not sure how no one brought this up until recently, but the attack can be much simpler. None of CT’s proofs (audit or consistency proofs) will detect mis-issuance of a certificate by a rogue CA, not even if gossip of STHs (signed-tree-heads) successfully occurs. On the other hand, if CT switches to using SCTs for gossip, that might successfully catch the CA responsible if the MITM leaves and if the server software keeps track of all the certs it issued. It will not help, however, if a revoked certificate was used for MITM.”

    From: https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/

    Client Certs

    Your bullet point on client certs is good.


    The section on DANE doesn’t mention any of the problems with it.


    As per the first link above, it doesn’t stop MITM attacks:

    > You’d think, for all its deployment expense, the forklifting out of incompatible networking code, and the required adoption of a government PKI running 1990s crypto, DNSSEC would at least nail its marginally valuable core use case.
    > Nope.
    > DNSSEC doesn’t secure browser DNS lookups.
    > In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
    > Why? Because there are two DNS security problems. The first is somewhat esoteric, and allows servers to exploit the way DNS records refer to one another in order to add a bogus record for VICTIM.ORG to a lookup for EVIL.NET. The latter is obvious and allows any attacker with access to the network to simply spoof entire DNS responses. The committee designing DNSSEC split the baby and chose the former problem over the latter.
    > Even if DNSSEC was deployed universally and every zone on the Internet was signed, a coffee-shop attacker would still be able to use DNS to man-in-the-middle browsers.


    The section on Convergence, similarly, could mention some of the problems:



    You may want to link to this article on TACK as tack.io is down for me: https://lwn.net/Articles/499134/

    It’s essentially the SSH approach, which is decent.

    Some notes:

    – Maybe another row is needed for “protects on first visit”? TACK doesn’t protect.
    – I would also add a row to consider expiration dates. Note that with DNSChain SSL/TLS certs no longer need expiration dates. Sysadmins just update the fingerprint that’s stored in the blockchain and all is good. With TACK, an automated system for re-generating keys would be needed, and that means every 30 days (or w/e the number is) a MITM attack becomes possible.
    – TACK allows TACKs to be retrieved via a “subscription” to some third party. If this is the primary mode that it ends up being used in, then that means that rows 13 and 14 should be “No” for TACK. Maybe add an asterisk to note those.


    Nightmare for users (as Cert Patrol users like me can tell you).

    Summary of table suggestions

    Certificate Transparency: Rows 6 & 7 either need asterisks or to be changed to “Maybe”. It’s still possible attacks can go undetected within that system as described in our blog post (because Monitors would need to monitor all the logs for all domains, and they are unlikely to do that).

    DANE: Rows 4, 5, 6 and 7 should be changed to “Maybe” as per notes above.

    TACK: Rows 4,5,6,7 need asterisks or “Maybe” because it does not protect on first-visit.

    Pinning: Same recommended changes as TACK (doesn’t protect on first visit).

    DNSChain: A footnote for row 14 is needed: the word “third party” does not apply in the case of DNSChain running on a home router, a personal server, or even locally on the machine in tandem with a blockchain thin client.

    Additional Row: Usability

    Values in [“good”, “questionable”, “poor”].

    For example, client SSL certificates, although they provide strong protection, they maybe be infeasible due to usability issues. How do you get your client certs from one device to another? Not possible in any meaningful way currently.

    Similarly, Pinning does not provide meaningful protection because users have no way to know whether the new fingerprint they’re seeing is legit. Cert Patrol is a wonderful example of this. Similar issue with TACK.

    With DNSChain, things like BlockchainID become possible (which makes it simple to use multiple identities across multiple devices without needing to transfer any keys): https://github.com/okTurtles/blockchainid

    Sorry again that it’s taken me this long to get back to you!

    Kind regards,
    Greg Slepak

  2. #2 by Greg Slepak on February 21, 2015 - 10:39 pm

    Inspired by some of the reading I did on this, I updated our docs with comparisons on TACK and HPKP:


    Copied here:

    Both TACK and HPKP are mechanisms for doing public key pinning for individual websites.

    These mechanisms are similar to how SSH uses a known_hosts file to store the fingerprints of public keys it encounters on a “Trust-On-First-Use” (“TOFU”) basis.

    The problem with these mechanisms is:

    – They break websites when the public key needs to legitimately change.
    – In the case of TACK, the TACK public key needs to change very frequently (at least every 30 days). This defeats the purpose of pinning, as a MITM does not need to wait long before they can present a fraudulent key that the user has no way to know is legitimate.
    – These mechanisms assume that client software has its current time set properly, and they break when that’s not true.

    While DNSChain does use public key pinning, it doesn’t have these problems because there is only one pin that is ever required: the pin to DNSChain itself, which is easily verified once only at setup.

Comments are closed.