Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

2/12/2013
02:41 PM
Connect Directly
Twitter
Facebook
Google+
LinkedIn
RSS
E-Mail
50%
50%

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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15564
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be map...
CVE-2020-15565
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs....
CVE-2020-15566
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, o...
CVE-2020-15567
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes...
CVE-2020-15563
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM g...