Many of the Internet’s secure protocols rely on Certificate Authorities(CA)s to issue certificates that we can trust. These certificates are responsible for ensuring that servers are who they say they are. Without this assurance, malicious actors can impersonate the true server, or degrade the Transport Layer Security(TLS) protocol to surreptitiously monitor traffic.
What happens when CA’s are subverted, or otherwise issue malicious certificates? A prime example is the case of Dutch CA Diginotar. In August of 2011, someone penetrated Diginotar’s security and issued at least 500 fraudulent certificates in their name. According to security company F-Secure, these fraudulent certificates were most likely used to impersonate popular websites visited by Iranians through Man In The Middle Attacks(MITM) and identify Iranians critical of their government.
This was not an isloated incident, nor the first time this had happened. In January of 2013 CA Turktrust admitted to having accidentally issued two intermediate certificates in 2011, which allowed the recipients to issue further certificates in Turktrust’s name.
Also in March of 2011 CA Comodo was breached and nine fraudulent certificates were issued. Luckily in this case the breach was noticed almost immediately and the certificates revoked before they could be used.
Because of these incidents and the continued reliance on CAs as trust gatekeepers, it’s clear we need a means to identify these kinds of attacks in the future. It’s also clear that relying on a large set of CA’s which are hardcoded into our browsers is probably not the best way to ensure our security.
The Internet community’s response to these kinds of attacks has taken one form in the IETF working group on Public Notary Transparency. This working group’s first deliverable was RFC 6962, which describes the Certificate Transparency protocol. Certificate Transparency is a method for, “publicly logging the existence of Transport Layer Security(TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority(CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves.” In addition to the IETF working group, certificate-transparency.org is a great place to learn about Certificate Transparency.
RFC 6962 describes a public log which can be appended to, but not otherwise modified. This public log can then be inspected by anyone. The idea is that by having a public distributed log of every certificate ever issued, breakins and malicious behavior such as what occurred at Diginotar, Turktrust, and Comodo can be caught by auditors before it causes too much damage. There is no requirement for CAs to append their issued certificates to this public log. Well acting CAs have it in their interest to eventually all use it, since CAs using the public log will be inherently more trusted than those which do not.
In addition to describing the public append only distributed log system. Certificate Transparency also defines two other components, monitors and auditors. Monitors are servers that periodically check the public log for suspicious behavior. They can be run by anyone, and will probably use heuristics, or algorithmic classifiers to discover bad behavior. Think of methods that credit card companies use to detect misuse of credit cards, although with hopefully fewer false positives. Certificate Transparency also defines auditors. Auditors are responsible for verifying the cryptographic integrity of the public distributed log, and verifying that specific certificates appear in the logs. Monitors and auditors may end up having much functionality cross over, but RFC 6962 defines them as separate components.
Now that you’re an expert on TLS Certificate Transparency, let’s talk about DNS-Based Authentication of Named Entities, or DANE. DANE is another answer to this type of threat. DANE is a way for computers to verify the TLS certificates presented by the servers they connect to are the correct certificates. It uses DNSSEC to host a hash of the correct TLS certificate, which is then signed with DNSSEC to ensure its authenticity. Operators of a server or website publish a hash of their TLS certificate in DNS, then cryptographically sign it using DNSSEC. When a client connects to said server, they can test the certificate proposed by the server against the signed hash stored in DNS. This mitigates MITM attacks since the attacker must also control DNS. DANE is described in RFC 6698.
This is not just about web browsers and user facing software, the problem space also extends to humanless computer-to-computer communications. We’ve written about how DANE makes it easier for operators to deploy STARTTLS for things like the Simple Mail Transfer Protocol(SMTP). That’s really just the start. There’s no reason why DANE cannot be used for any protocol which implements STARTTLS; such as NNTP, or IMAP/POP3, XMPP, FTP, and LDAP.
Both Certificate Transparency and DANE remove a reliance on the trustworthiness of CAs. Certificate Transparency does so by logging all TLS certificates issued by CAs, and then subsequently auditing them. Whereas DANE does so by allowing operators to sign their own TLS certificate using DNSSEC. DANE even allows for operators to create their own TLS certificates, without requiring a CA to issue it at all. Both protocols remove a need to trust CAs implicitly, and will hopefully allow us to move away from a world in which CAs remain hard coded in web browsers. The more we push decisions concerning trust out towards the edges of the network, the better off we’ll all be.
Both Certificate Transparency and DANE are relatively new, and barely deployed. However, one can imagine a future in which CAs have entirely ceased being the trust-anchors that they currently are. Instead replaced with both a massively distributed logging mechanism, and the hierarchical system of trust built upon DNSSEC. We’re getting there. With deployments of DNSSEC increasing, authenticating remote TLS certificates via DANE is becoming more feasible every day.
If you would like to learn more about Certificate Transparency, please visit certificate-transparency.org. If you would like to learn more about DANE, please visit our resource page on DANE. If you would like to get started with deploying DNSSEC please visit our DNSSEC resources, or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have a Certificate Transparency, DANE, or DNSSEC case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!