At the (heart) bleeding edge

Heartbleed IllustrationThe news about a possibly very nasty bug in the popular OpenSSL library got my attention almost weeks ago which hit out of the blue like a bombshell. Dubbed Heartbleed, this bug can potentially leak private keys installed at servers which make use of the affected libraries I learned, and shortly after that the first revocation requests due to the bug report started to come in at StartSSL.

It also didn’t took a long time until the first calls for removal of the StartCom root from browser came across Twitter feeds and at the Mozilla bug reporting system with the claim that most StartSSL issued certificates will stay vulnerable. Upfront, I can easily refute this claim by confirming almost 2000 revocations since the disclosure of Heartbleed, still counting. I’d say, let the certificate revocation lists (CRL) do the talking and I’m certain that StartCom will have over time proportionally a similar amount of revocations to show as most competitors.

But why this outcry against the StartCom Certificate Authority? Because we dare to ask to get paid for a service we provide…. OK, well…it’s not that easy:

Early on when StartCom was still a very young CA which set the goal to provide an alternative to the existing certificate authorities, I realized that in order to allow free issuance of SSL certificates there must be a price tag for revocations. The costs for issuing a certificate (depending on the verification level) is that minor that we can call it zero - in short, the effort and cost is that low, we can provide them without charge. Instead we charge a fee where the real costs apply, e.g. cost and effort originating. With that business model in place, we kept our promise to the Internet community and even after having reached a more significant market position, StartCom to this date still doesn’t charge any fees for the issuance of a certificate.

So how can StartCom sustain its operations over the years? Fees are applied for those services that require an effort (human resources) and incur other expenses. Therefore, for a higher verification a fee is charged, the certificates upon which the verification is based is again free of charge. And revocation of an existing certificate is also charged a fee mainly because of two reasons:

  • First, since the certificates can be obtained without charge, it would be very easy for anyone (friend or foe) to request a certificate, request revocation and repeat this endlessly. And we couldn’t stop it the same way we can’t stop anyone from anywhere to apply for a certificate - which we also don’t want to.
  • Second, the revocation infrastructure is fairly expensive involving an array of servers and the popular content network distribution (CDN) provider Akamai. The beneficiaries of this system are first and foremost those that need it, e.g. those that need to have a certificate revoked for whatever reason.

Charging a fee for revocations prevents possible abuse of Startom’s services and provides some sort of insurance policy for the unlikely event of a necessary mass-revocation. In this respect, the interest of the collective is above the interest of the individual in relation of the sustainability and survival of the StartCom authority. Otherwise StartCom wouldn’t be able to maintain the current business model and would have to charge for every certificate the same way its competitors do.

This model of course works conveniently for all parties involved until now, except that some subscribers suddenly don’t want to keep their part of the bargain. The majority understands and cooperate fully, but there are those that cry foul. Unjustified though, because StartCom has clearly disclosed this fact at its web sites and policies and has never hidden it.

Netcraft reported that up to 17% of the current web servers could have suffered from the Heartbleed bug - but most likely only a small minority of private keys were actually ever leaked. According to my understanding of this vulnerability, for this to happen an attacker must have performed the attack on the server right after a restart when the private key is loaded into memory and still within the first 64K allocated memory space - this usually requires some prior knowledge. It’s however far easier to obtain from an affected server other data such as user names and passwords as they are loaded into the memory and then readable by the attacker making it not less dangerous.

In this respect here some additional points:

  • Based on the above assumption, I believe that most low-profile sites don’t have to worry about an actual key leakage, but since an attack doesn’t leave any traces it will be the subscriber’s responsibility to make an assessment if and how they were affected by a vulnerable server.
  • For private sites that are usually not visited by the public (administrative panels for example), changing the host name, deleting the previous DNS entry, obtaining a new certificate and never visit the original site again might work too. Many of the free Class 1 level certificates are used for such purpose.

The full extend of this bug is still unknown yet and the full implications will of course have to be learned over time - for example considering that a certain major browser doesn’t check for any revocation status at all and has no protection against this bug. Another example the huge number of revoked certificates necessary by one of our competitors due to the bundling of multiple different unrelated sites and domains and repeated re-issuing which placed their CRL size above the 4MB. And then StartCom’s business model which implies a fee for revocations which isn’t the common approach.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.

Other Posts
Cyber War

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

You must be logged in to post a comment. Click here to login.

Reader Comments

ysl tassel Satchel…

YSL Proves More Popular Dead than Alive…