Chrome users oblivious to Heartbleed revocation tsunami
In the aftermath of Heartbleed, it has become clear that revoking potentially compromised certificates is essential. On Thursday, CloudFlare announced it was reissuing and revoking all of its SSL certificates. The effects of CloudFlare’s mass revocation are evident in a single Certificate Revocation List (CRL) belonging to GlobalSign, which grew by almost 134,000 certificates.
So, we @CloudFlare decided to revoke/reissue all our certs: https://t.co/1g4GRFztB0
— John Graham-Cumming (@jgrahamc) April 17, 2014
The vast number of CloudFlare certificates is due, in part, to the way in which it serves content over SSL. In order to work around the lack of support for Server Name Indication (SNI) in some older operating systems and mobile devices CloudFlare uses GlobalSign’s Cloud SSL product. CloudFlare’s SSL certificates make use of the Subject Alternative Name (SAN) extension, which allows an edge node to use a single certificate for multiple domains. When a new CloudFlare customer enables SSL, CloudFlare reissues an existing certificate with the new customer’s domain added to the existing list of other customers’ domains.
The number of certificates revoked per hour since 7th April. GlobalSign’s OV CRL at http://crl.globalsign.com/gs/gsorganizationvalg2.crl and other CRLs have been separated.
As a result of CloudFlare’s revocations, GlobalSign’s CRL at http://crl.globalsign.com/gs/gsorganizationvalg2.crl has ballooned in size and now weighs in at 4.5MB. The CRL is hosted at CloudFlare itself but has nonetheless experienced some performance problems. However, the CRL’s performance problems will not have had a significant effect on internet users, as most major browsers use OCSP in preference to CRLs and GlobalSign’s OCSP responder did not have any performance problems.
Time to connect to http://crl.globalsign.com/gs/gsorganizationvalg2.crl from Pennsylvania
Time to connect to http://ocsp2.globalsign.com/gsorganizationvalg2 from Pennsylvania
However, most Google Chrome users are left in the dark, as Chrome performs neither type of check for non-EV certificates by default. Instead of conventional revocation checks, Google Chrome relies on an aggregated list of revocations, dubbed CRLSets, which are compiled by Google. The revocations from GlobalSign’s CRL have not yet appeared in Google’s CRLSets and hence Chrome users will not be warned if presented with a potentially compromised, but revoked, CloudFlare certificate.
The CRLSets deliberately do not cover all CRLs in an attempt to reduce the total size of the aggregated list. In effect, Google has traded the completeness of their revocation checking for a speed advantage over rival browsers as downloading CRLs or making OCSP requests imposes a performance penalty.
Google Chrome setting to enable revocation checking.
However, it is possible to configure Google Chrome to check for revocation. There is a checkbox in the Advanced settings menu to “Check for server certificate revocation”.
Debian: 2907-1: Security Summary: Summary
(Apr 16) Security Report Summary
(Apr 9) Security Report Summary
Red Hat: 2014:0413-02: java-1.7.0-oracle: Critical Advisory
(Apr 17) Updated java-1.7.0-oracle packages that fix several security issues are now available for Oracle Java for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having Critical [More…]