CA Security Council (CASC) members Trend Micro, Go Daddy, and Symantec participated in a discussion panel at the 2014 RSA Conference in San Francisco on February 24 entitled “New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet.” Panel members included Kirk Hall of Trend Micro (Moderator), Wayne Thayer of GoDaddy (Panelist), and Rick Andrews of Symantec (Panelist).
Introduction to the Topic
Hall began by introducing the topic – all three alternative technologies (Certificate Transparency or CT, Certificate Authority Authorization or CAA, and Certificate Pinning) are intended to make the internet safer by dealing with mis-issued digital certificates, including so-called “rogue” certs like those obtained by a hacker from the now-defunct Diginotar Certification Authority (CA). Mis-issued certs generally present the greatest potential danger when they are for the most popular fraud target domains, such as mail.google.com, login.yahoo.com, login.live.com, etc.
The rate of mis-issuance of certificates is extremely low, Hall explained, and in a normal internet environment a rogue cert for a top fraud target domain such as mail.google.com simply won’t work on any other site, as the domain name in the certificate won’t match the hacker’s domain name and the browser application will throw up a warning to users.
However, Hall noted that rogue certs could be used in Internet environments controlled by others (such as enterprise networks, public wifi, etc.), through certain fraud procedures such as DNS spoofing and poisoning, and most significantly, in closed countries that can corrupt the DNS and misdirect users to fake sites (the certificate mis-match warnings will not work in this situation). For this reason, Hall said, it’s important to consider these new technologies which are intended to detect or even prevent the mis-issuance of certificates.
Certificate Transparency (CT)
Wayne Thayer of GoDaddy then described the basics of CT, and how it could help detect but not prevent the issuance and use of rogue certificates. CT is described in RFC 6962, although that draft standard is marked “experimental” and is still unfinished. The goal of CT, Thayer stated, is to make certain that all certificates are first logged in multiple CT logs that are publicly available to the world before the certs are delivered to customers. How does CT work?
Thayer explained that CT’s most common implementation would require an issuing CA to first create a “pre-certificate” with all the intended customer data, including certificate serial number, but containing a “poison extension” that applications won’t understand (so the pre-cert could never be used if it got into the wild), and then have the pre-cert signed by multiple CT logs (run by the CA or others) to obtain SCTs (Signed Certificate Timestamps). The signed pre-certs would also be logged in multiple public CT log using Merkle hash trees to detect inconsistencies and ensure that the log data could not later be altered.
Once the minimum number of SCTs had been collected by the CA, they would be transferred to the “real” certificate (with the same serial number as the pre-cert in the CT logs, but without the poison extension) and the cert would then be sent to the customer.
What’s the point of this procedure? According to Thayer, when a user’s browser encounters the cert it would first check to see if the cert had enough SCTs from trusted CT logs to qualify as a trusted certificate, and that those SCTs were cryptographically valid – if yes, the user would proceed to the secure site and see the normal trust symbols for SSL. If not, the browser could hard-fail and not allow the user to visit the site, or could put up a warning instead.
The whole purpose of this SCT checking by a browser, Thayer explained, is to prove to the user that the cert data is posted in one or more public CT logs. This is meant to reassure the user that someone – perhaps the real domain owner for the cert (such as Google, Yahoo, or Microsoft for the examples above) could monitor all issued certs to determine if any rogue certs had been issued for their domain. There is no way to do this today with 100 percent certainty (although web crawling applications already do a good job of finding and recording nearly all issued certs on the public-facing internet). Thayer added that if a cert doesn’t contain the required number of trusted SCTs, that implies to the user that the cert data may not be viewable anywhere to the public, and so the domain owner and others may not have had a chance to look at the cert to determine if it’s a rogue cert or not. For that reason, a cert without enough valid SCTs would be treated as untrusted (even if it was otherwise a properly issued cert).
There are two other possible implementations of CT, Thayer said, but both require technical action by the server operators (either delivering the required SCTs through a TLS extension or by OCSP stapling), and these alternatives are not likely to be adopted.
As to the CT logs, Thayer stated the proponents of CT believe that the whole world (“monitors”), not just domain owners, will want to download the data for all issued certs and scan it to look for suspicious certs and report their findings somewhere. The concept is that this monitoring process will help find all rogue certs and lead to their revocation by the issuing CA.
Thayer noted, however, that CT is not a perfect solution due to the following limitations: (1) there will be a delay – perhaps as much as 24 hours – between the time a cert is issued and the time it’s posted on a CT log, so a rogue cert could be used for that period before anyone would have a chance to detect it on a CT log (and maybe longer if no one is monitoring the CT logs for that domain), (2) CT requirements interrupt the normal process of cert issuance, and introduce potential vulnerabilities, (3) the CT standard is not finished, and there are significant unanswered questions, (4) there are no security requirements around running a CT log, and it’s unclear who will be allowed to run a log (and if the logs are not secure, they won’t solve the rogue cert problem) or how a large number of CT logs will be managed.
Other CT limitations noted by Thayer include: (5) CT only works if someone is monitoring for a particular domain, (6) monitors have the potential to create lots of false alerts, (7) CT can’t prevent or mitigate an attack (e.g. the Diginotar attach) – it only detect them after they happen, (8) CT adds unknown cost and complexity for CAs; (9) CT logs must be highly available – otherwise, they can block cert issuance, (10) a public log of all customer certificates before issuance creates privacy and data leakage concerns, and finally (11) the SCTs increase TLS payload.
Thayer concluded by noting that Google is requiring all CAs to implement CT for Extended Validation certificates by July 2014, which is a highly ambitious schedule. EV certs without the required number of SCTs will not be displayed as EV in Chrome starting in 2015. Google may require CT for all SSL certificates at a later date.
Certificate Authority Authorization (CAA)
Rick Andrews of Symantec next described CAA, which is specified at RFC 6844. Under CAA, a domain owner can designate in the DNS record for its domain which Certification Authorities (CAs) are authorized to issue certificates for the domain. When a CA receives a certificate order from a customer, under CAA it must first check the DNS record for the domain to see if it’s listed as an authorized CA for the domain – if not, the CA must take additional steps (although the exact steps are not listed in the RFC) or refrain from issuing the cert.
Andrews explained that there are no technical requirements required for CAA other than entry of the authorized CAs in the DNS record (which is optional with the domain owner), so CAA is a low-touch solution to the rogue cert problem, and unlike CT and Pinning, CAA can actually prevent cert mis-issuance if properly implemented (as each participating CA will refrain from issuing a cert to an imposter if the imposter can’t update the DNS record to authorize that CA for issuance). A domain owner would not be locked into doing business with a single CA, but could list multiple authorized CAs in its DNS record.
Andrews did note certain limitations with CAA: (1) the current spec gives CAs a lot of leeway on how to respond if the CA is not listed in the web site’s CAA record, (2) large customers may have multiple cert buyers who are not the same people who maintain the company’s web sites/DNS records, so there could be coordination issues and difficulty in getting all authorized CAs listed in the record, (3) CAA raises possible competition issues and could make it hard for new CAs to get business if a customer has indicated a different preference in the DNS record, (4) to be effective, the majority of CAs would have to adopt CAA and abide by the limitations stated in the DNS records, and (5) CAA is not yet supported in many DNS implementations. Andrews also noted that CAA is most secure with DNSSEC, which is not yet widely deployed, but can also be used with DNS.
Certificate Pinning
Rick Andrews next covered the essentials of Certificate Pinning, which is described in an IETF Internet-Draft memo called “Public Key Pinning Extension for HTTP” found here. Pinning works as follows: (a) the domain owner pins a hash of one or more public keys in the cert chain to the domain’s website, (b) on a user’s first time visiting a site, the site returns the public key pins to the user’s browser via HTTP headers, (c) the browser then checks that at least one pin is valid for the cert chain presented, and (d) the browser caches pins for the site in case none are received on next visit. Pinning reduces the incidents of man-in-the-middle attacks due to compromised CAs by having the user’s browser compare cached hashes of known valid keys for a particular web site with the hashes of the keys securing the web site currently being visited – if there is no match, a report is sent or access is blocked, or both, Andrews noted.
The chief benefits of pinning, Andrews continued, are as follows: (1) site owners who care most about mis-issued certs (e.g., top fraud targets) have sophisticated IT groups capable of implementing Pinning, while other domain owners don’t need to bother, (2) Pinning allows each site owner to optionally pin one or more overlapping keys to help transition to new certs securing the site over time, and (3) site owners can pin keys for end-entity, intermediate or root certs. Andrews added that Chrome’s hard-coded pins have already successfully detected mis-issued Google certs (e.g., in the Diginotar case), and Pinning can scale beyond those pins currently hard-coded in browsers like Chrome.
However, Andrews stated, Pinning is also not a perfect solution: (1) pinning requires “trust on first use” – the pins that are downloaded from a site on a user’s first visit. Preloaded pins such as Google’s address this, but aren’t scalable, (2) incorrect pin set can block all access to a site (“bricking”), which would be disastrous for site owners, (3) Pinning may be beyond the technical capabilities of many site operators, resulting in possible incorrect implementation (but top fraud target domains probably can implement Pinning correctly), and (4) under limited circumstances, Pinning could be abused to allow tracking of users. Pinning also doesn’t prevent mis-issuance of certs, Andrews added, but only helps users with detection and warning.
Final Comparison of CT, CAA, and Pinning
Wayne Thayer wrapped up the panel session with a side-by side comparison of CT, CAA, and Pinning, based on several tables in the panel’s presentation. Each solution has its strengths and drawbacks, and each imposes differing requirements on CAs, domain owners, and browsers.
The panel’s full presentation can be viewed here.
