02:41 PM
Connect Directly

Tech Insight: New CA Group Has Big Names, Small Impact

The Certificate Authority Security Council will promote new technologies and best practices in the PKI, starting with improving certificate revocation-checking, but any changes that would have a real effect soon are too disruptive to consider

As reported earlier today on Dark Reading, a group of big-name certificate authorities (CAs) have formed an organization called the Certificate Authority Security Council (CASC) to promote best practices in the use of the public key infrastructure on the Internet. The founding members are Comodo, DigiCert, Entrust, GlobalSign, Go Daddy, Symantec, and Trend Micro.

CAs such as Symantec, Go Daddy, and Comodo sell digital certificates and services related to them, but what they are really selling is trust. Users of digital certificates -- website administrators, developers, end users, and pretty much everyone -- rely on the CA to authenticate the identity of the parties with whom they interact.

Compromises in this system aren't especially common -- as far as we know -- but when they happen, it's big, embarrassing news. Here are some examples:

If trust in the system breaks down, then the ability to perform sensitive operations on the Internet is threatened, so the CAs need to do whatever they can to keep the system trustworthy, or at least to keep up people's confidence in them. For this reason they have formed organizations to improve trust. For example, the CA/Browser Forum created the EV-SSL system; these are the special, very expensive digital certificates that turn your browser address bar green.

The CASC's first campaign will be to increase and improve the use of certificate revocation. Revocation is an essential element of trust in the PKI and played an important part in all four of the breaches listed above. In every case, false certificates were issued by attackers using the agencies of the CA. These certificates were revoked by the CA. The way the system works, the systems that rely on a certificate are supposed to check to see whether it has been revoked.

Revoked certificates classified as untrusted by Windows

There are two systems for revocation-checking: CRL and OCSP. CRL (certificate revocation list) is a simple list, published by the CA, of unique IDs of revoked certificates. Because these lists can get rather large, an alternative system was built. OCSP (Online Certificate Status Protocol) is an interactive protocol that systems can use to query a CA for the status of a specific certificate.

Both systems have downsides: Large CRLs consume bandwidth, and OCSP requests have multiple round-trips and latency. For these and other reasons, it's disturbingly common for software not to bother checking for revocation. Java, for instance, is set by default not to check for certificate revocation (but nobody has accused Java of being a secure system lately).

To lower the cost of an OCSP transaction, CASC is promoting a technology called OCSP stapling (see section 8 of RFC6066 -- TLS Extension Definitions). Stapling allows the site that holds the certificate also to hold a signed OCSP response and to serve it to users as part of the TLS handshake.

Certainly OCSP stapling is a good thing, although exactly how much of a help it will be is controversial. Adam Langley, a top encryption developer at Google, is on record doubting its real-world value:

OCSP stapling has several issues. Firstly, the protocol only allows the server to staple one response into the handshake: so if you have more than one certificate in the chain the client will probably end up doing an OCSP check anyway. Secondly, an OCSP response is about 1K of data.

Remember the issue with overflowing the initcwnd with large certificates? Well the OCSP response is included in the same part of the handshake, so it puts even more pressure on certificate sizes.

I put these concerns to CASC, and its response was that, in most cases, the other certificate in the chain is a trusted CA, so no check will be necessary. It added that browsers cache these responses, further diminishing traffic, and that in the longer term, improvements to OCSP stapling will bring further efficiencies.

Who's right? I can imagine research using the EFF's SSL Observatory to determine how common it is for certificates to have untrusted CAs in their certificate chains. Perhaps the CASC would be willing to do it.

In the meantime, don't look to do a whole lot of OCSP stapling soon. Support for it is not especially common. The Nginx Web server just recently got support (the work was paid for by Comodo, DigiCert, and GlobalSign, charter members of CASC). Nginx is an open-source Web server designed for high-volume servers. In its most recent survey, Netcraft found Nginx on 12.85 percent of all Internet-facing Web servers. Presumably the work is portable to other servers, chiefly Apache.

It's not like I object to the work of the CASC: It's unobjectionable, even laudable. It's just hard to see it making a big dent in the problem. Having written many papers on OCSP over several years, I know that the need for revocation-checking isn't a secret. People who aren't aggressive about it now are willful in their irresponsibility. What can CASC really do for them?

The CA/BForum was originally going to have a broader mission, but it seems to be limiting itself to EV-SSL now, and many of the same companies are now forming the CASC for purposes that can only be called "similar." Something political is going on there. At least the CASC says it supports the CA/Browser Forum in its work.

In the meantime, there are others who dismiss the whole CA system and seek to go beyond it. TACK (Trust Assertions for Certificate Keys) is a proposal for TLS extensions to allow clients to "pin" (as opposed to "staple"?) to a server-chosen signing key. TACK claims to be fully compatible with the existing CA infrastructure.

This stuff moves slowly. Even a relatively incremental change like OCSP stapling will take many years to become at all common because it requires code changed in every client and server. Same with more radical changes like TACK. The only way to speed change in a situation like this would be to disrupt business -- for instance, by deprecating support for older standards. This does happen, but slowly and rarely. But for the foreseeable future, we've made our PKI bed, and now we're going to have to sleep in it.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Follow Larry Seltzer and BYTE on Twitter, Facebook, LinkedIn, and Google+: - @lseltzer @BYTE - Larry Seltzer BYTE - Larry Seltzer on LinkedIn BYTE - Larry Seltzer on Google+ View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-04-01
The PRNG implementation in the DNS resolver in Bionic in Android before 4.1.1 incorrectly uses time and PID information during the generation of random numbers for query ID values and UDP source ports, which makes it easier for remote attackers to spoof DNS responses by guessing these numbers, a rel...

Published: 2015-04-01
The default slapd configuration in the Debian openldap package 2.4.23-3 through 2.4.39-1.1 allows remote authenticated users to modify the user's permissions and other user attributes via unspecified vectors.

Published: 2015-04-01
OpenStack Compute (Nova) before 2014.1.4, 2014.2.x before 2014.2.3, and kilo before kilo-3 does not validate the origin of websocket requests, which allows remote attackers to hijack the authentication of users for access to consoles via a crafted webpage.

Published: 2015-04-01
The PRNG implementation in the DNS resolver in Mozilla Firefox (aka Fennec) before 37.0 on Android does not properly generate random numbers for query ID values and UDP source ports, which makes it easier for remote attackers to spoof DNS responses by guessing these numbers, a related issue to CVE-2...

Published: 2015-04-01
Mozilla Firefox before 37.0, Firefox ESR 31.x before 31.6, and Thunderbird before 31.6 allow remote attackers to bypass the Same Origin Policy and execute arbitrary JavaScript code with chrome privileges via vectors involving anchor navigation, a similar issue to CVE-2015-0818.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.