latest updates from easySERVICE™
Many bad things will happen because of Heartbleed. One which will affect nearly everyone is a general slowing of performance owing to the need to revoke and reissue millions of SSL/TLS digital certificates and keys. The volume of such revocations has been increasing in the days since Heartbleed was announced to the world.
Netcraft, a research firm which monitors web sites and certificates world-wide says that the number of certificate revocations is at 80,000 and has merely begun. Very large SSL providers like Akamai are planning mass-revocations of customer certificates.
SSL/TLS certificates are used by Internet parties to prove their identity of each other. They are used for much more than secure web sites: Many VPNs rely on SSL for clients and servers to prove identity to each other.
When a certificate becomes untrustworthy and is revoked, a unique identifier for the certificate is added to a file called a CRL (Certificate Revocation List). Each certificate contains a field for the specific CRL to check to see if it is revoked.
There are two problems with this process: CRLs can grow to an unwieldy size, which creates a performance problem both for the client and server; and many clients aren’t very good about checking for revocation. Consider the nearby image, a screen grab from Google Chrome Settings: By default, perhaps as a performance measure, Chrome does not check for certificate revocation. In fact, these are just two of the problems with certificate revocation. In the real world it fails in many other ways.
Research shows a measure of CRL growth. It’s actually not clear whether the graph, which shows “CRL counts of sixteen different CA’s since April 1, 2014,” shows the size of CRLs or the number of them, or whether it’s a measure of growth per day. But it’s certainly growing. Netcraft says that if all the certificates affected by Heartbleed were to be revoked, CRLs would grow by about 35%.
Because of the limitations of CRLs, a new standard called OCSP (Online Certificate Status Protocol) was developed years ago so that a client could check with the CA for the status of a single certificate. In normal cases, where checks are done one at a time, this approach saves a lot of network bandwidth. At a time when large numbers of revocations are being performed, reliance on OCSP can be a large burden on the CA systems. Note: Firefox no longer supports CRLs at all, relying entirely on OCSP.
Source: Associated Press