Shameful Security: StartCom Charges People To Revoke SSL Certs Vulnerable To Heartbleed
from the and-fuck-you-all-too dept
Yesterday, we wrote about just how terrible the Heartbleed bug in OpenSSL is. It's been generating plenty of discussion, with folks like Bruce Schneier calling it "catastrophic" and saying that "on the scale of 1 to 10, this is an 11." It's a pretty big deal. So you'd think that everyone would be scrambling to help plug the vulnerability as painlessly as possible. And most companies have been doing that. But one -- StartCom -- apparently sees this as an opportunity to rake in cash and to screw over those most vulnerable.StartCom is a free SSL Cert authority, and on the company's website, it claims it offers this service for free "because we believe in the right to protect and secure information between two entities without discrimination of race, origin and financial capabilities." Except, that's not quite how things are playing out in reality. As is being actively discussed over at HackerNews and via the StartSSL Twitter fee, the company is trying to charge people to revoke the vulnerable certs. Update: And, yes, they're even charging those who are on their premium paid service tiers as well -- and often charging exorbitant rates.
While the company has generally charged for revoking certs, many people pointed out that with a vulnerability of this magnitude, that's both ridiculous and dangerous. However, the company doesn't seem to care.
It's upon the subscriber to take appropriate action since the certificate authority can't enforce which software to use. The terms of service and related fees will not change due to that.When it was pointed out to the company how serious a vulnerability issue the company started to get snotty with its own uses:
We do understand the situation very well, thanks.... This is not our fault as well. We do not see any reason to provide this paid service for free. We have enough other free services already if you didn't mentioned it.People began challenging the company on Twitter, and it's taken that same snotty "we don't give a fuck" attitude to them as well:
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: heartbleed, openssl, revocation, secure certs, security, startssl, vulnerability
Companies: startcom
Reader Comments
The First Word
“startssl.com declares intention to commit corporate suicide
You know, when the Morris worm hit all those years ago, we all put aside our differences and our squabbles because we realized that the shit had hit the fan and our only chance of straightening out the mess was to work together. Immediately.So everyone who could help, did, without any thought to what the bean counters or the administrators or the policy makers or anybody else irrelevant to the problem-at-hand might say or do. That spirit of cooperation was the key to resolving the issue -- which we did pretty quickly.
But I see that startssl.com doesn't get that. They don't understand their first operational responsibility is not to themselves or their profits: it's to the entire Internet, because of course that's EVERYONE'S first operational responsibility, the one that trumps all others at all times. (Think about it. Without the Internet, would startssl.com even exist?) It's a pity that they don't get this, but soon enough it won't matter: they're about to find out that they're expendable, disposable, replaceable.
I suspect that lesson will be taught on an expedited basis.
Subscribe: RSS
View by: Time | Thread
Time to return the favor I'd say
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
What makes this worse...
My e-mails with StartSSL:
[ link to this | view in chronology ]
Re: What makes this worse...
[ link to this | view in chronology ]
Yep... finding a new CA
But with the patching we did to our servers, and the need to revoke/reissue the cert - paying ~$25 to revoke it seems ridiculous. It's especially onerous considering our cert is going to expire in less than 2 months time anyway.
As such, I'm looking at alternatives - I found a CA that offers free wildcard certs to FOSS projects that meet their criteria, and I'm exploring that option now. Either way, we'll need to pay for the revocation... sadly.
[ link to this | view in chronology ]
Re: Yep... finding a new CA
Just move over to another CA and let the old ones expire.
To bad DNSSEC and DANE are not production-ready yet.
[ link to this | view in chronology ]
Re: Re: Yep... finding a new CA
That doesn't really address the problem of having compromised certificates out in the wild. If you just change the certificates you use but don't revoke the old ones, crooks can still create (for example) web pages that authenticate to the users that they belong to you.
If you're a bank, say, then users will still feel comfortable entering very sensitive information into the site without any indication that the site is fraudulent.
[ link to this | view in chronology ]
Re: Re: Re: Yep... finding a new CA
While I seriously doubt that our FOSS project is going to be the target of such a plan in the next two months - the responsible thing to do is simply revoke the cert and give our users some peace of mind that we've done everything *we* can do to make it right.
[ link to this | view in chronology ]
Re: Re: Re: Re: Yep... finding a new CA
"the responsible thing to do is simply revoke the cert and give our users some peace of mind that we've done everything *we* can do to make it right."
It warms my heart incredibly to hear this sentiment. My hat is tipped to you, sir.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Yep... finding a new CA
In any case, not sure anyone will see this now, but when we finally did revoke the StartCom cert - they did so with no charge.
I offered the reason for the revocation that our private key could have been leaked due to the Heartbleed vulnerability - so maybe they've had a change of heart (pun?) since this whole thing went down.
[ link to this | view in chronology ]
What CA offers free certs to FOSS projects?
[ link to this | view in chronology ]
Re: What CA offers free certs to FOSS projects?
https://www.globalsign.com/ssl/ssl-open-source/
[ link to this | view in chronology ]
startssl.com declares intention to commit corporate suicide
So everyone who could help, did, without any thought to what the bean counters or the administrators or the policy makers or anybody else irrelevant to the problem-at-hand might say or do. That spirit of cooperation was the key to resolving the issue -- which we did pretty quickly.
But I see that startssl.com doesn't get that. They don't understand their first operational responsibility is not to themselves or their profits: it's to the entire Internet, because of course that's EVERYONE'S first operational responsibility, the one that trumps all others at all times. (Think about it. Without the Internet, would startssl.com even exist?) It's a pity that they don't get this, but soon enough it won't matter: they're about to find out that they're expendable, disposable, replaceable.
I suspect that lesson will be taught on an expedited basis.
[ link to this | view in chronology ]
Re: startssl.com declares intention to commit corporate suicide
The Morris Worm used a buffer exploit to break into all those computers, an inherent security hole in the C language in which the language does not ensure that the space you're trying to put data into is large enough to accept the data you're putting in, and so if the programmer forgets to check this manually, the data can get written to other areas of memory and end up being used to hack the system.
This should have put the programming community on notice, but it didn't. A quarter-century later, people are still getting hacked by buffer overruns, including Heartbleed, for one very simple reason: people are still writing C code that's vulnerable to buffer overruns.
Make no mistake; this is inherently a problem in the C language. You don't hear about buffer overruns in Java or Pascal or Ruby or Python because the languages are designed in such a way that that's impossible. But Windows and *nix systems have to issue critical security patches on a regular basis because they're written in C, or in C++ or Objective-C, which are closely related and share C's flaws.
We know better than this. We have known better than this for longer than most people reading this post have been alive. I quote from Tony Hoare, one of the great pioneers in computer science, talking in 1980 about work he did in 1960:
And he's right; it should be. The Morris Worm put us all on notice, and the Heartbleed bug serves as a stark reminder that those who do not learn from history are doomed to repeat it. 34 years after Hoare's warning, and nearly a quarter-century after the Morris Worm, it's still not considered an act of criminal negligence by the law--or even generally considered a shameful act by one's peers in the computer programming community--to build an operating system, browser, or other network-facing software, or other software that has an inherent security requirement, in C.
It's about time that changes.
[ link to this | view in chronology ]
Re: Re: startssl.com declares intention to commit corporate suicide
[ link to this | view in chronology ]
Re: Re: startssl.com declares intention to commit corporate suicide
Heartbleed is worse than a buffer overrun. Actually, from what I understand, it's more of a buffer underrun - the buffer allocated is larger than is needed for the response, and the result is that the buffer contains "extra data" that is or was in memory at that location. The amount of data written to the buffer is not sufficient to wipe all the left over data. If they had done the sensible thing - which is to zero out the buffer - the problem might have been ignorable (who cares if you get an extra 64k of nulls back?) or caught more or less immediately because key portions of memory (such as the encryption key needed for future operations) would no longer be available.
[ link to this | view in chronology ]
Re: Re: startssl.com declares intention to commit corporate suicide
So I don't really get your point?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
How the fuck do you expect Eddy Nigg to mitigate the NSA?
How the fuck.
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Disagree
Rich says "They don't understand their first operational responsibility is not to themselves or their profits" but of course, that is their first, last, and only operation responsibility. It's not a charity, okay? It's not a tax-supported government service, okay? It costs them money to provide services so pay them. Sheesh.
[ link to this | view in chronology ]
Re: Disagree
The FREE certs are non-revocable, and they are very clear about that. You either wait for it to expire, or you choose a new subdomain (their free certs are limited to a single subdomain).
It's the PAID certs that they charge to revoke.
[ link to this | view in chronology ]
Re: Re: Disagree
You're right I misunderstood that. The article makes it sound otherwise (quoth "yes, they're even charging those who are on their premium paid service tiers as well" -- it's the "as well" that is hard to interpret any other way).
In any case, I don't know, yeah it's nice when companies give people a break but I'm not ready to cast them out when they decline to do so. If the cert problem were their fault, I could concede their assumption of responsibility, but it's not their fault so it's not unreasonable for them to ask for their standard fee in cleaning up someone else's problem.
That doesn't mean customers have to be happy about it. If you're not then find a new cert auth. I don't know a lot about cert auths but I assume there are many of them. I've dumped companies for smaller slights than this, so customers needn't shy from doing so.
[ link to this | view in chronology ]
Re: Re: Re: Disagree
Find a new CA who isn't in bed with NSA.
Maybe �instead� we should admit that the whole damn mess is b0rked.
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
While the system has some flaws in its implementation, it's a bit of an overstatement to say it's all borked. Just the commercial CA aspect of it.
For many purposes, there is no reason whatsoever to use any commercial CA at all. In my own systems, for example, I run my own trusted root CA that signs and authenticates the keys used by my other services. I have 100% control and nobody can demand I use a compromised root CA cert.
The downside of this is that I have to manually install a trusted root cert on new machines I bring into the fold that use these services. This makes my services less than totally convenient for use by the general public -- but the general public isn't using my servers anyway, so that doesn't matter.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Disagree
And also the fact that TLS cert revocation is more a baroque joke at the internet's expense than a reliable mechanism.
i) both mechanisms we have for doing cert revocation suck.
ii) Multiple browsers don't do revocation checks by default.
iii) Even the ones that do 'fail open', so if the server's overloaded they just trust the cert.
iv) Non-browser apps are even worse at revocation checking. You know, small things like postfix don't do any revocation checks at all. Some mail clients do, some don't, who knows, it's all a magic sauce sandwich. XMPP clients don't seem to.
Internet security: we're really just not very good at this stuff.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Disagree
�It's only a flesh wound!�
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Disagree
Absolutely true. How certificate revocation is handled is messed up and a major (perhaps the major) problem with how the trust chain is maintained.
[ link to this | view in chronology ]
Re: Re: Re: Disagree
I looked at their "Class 1" cert option, but as with anything, you get what you pay for. It is completely non-revocable, it doesn't support wildcards (which would be absolutely insane if you couldn't revoke it anyway), and there's really not much guarantee of identification for your users. It's just an easy way to get a "lock" icon working in the URL bar of a user's browser without the big scary warning messages that most browsers present now.
As such, we chose the Class 2 Verified wildcard cert, and have renewed it a couple times without issue. As it turns out, we were nearing our expiration, and would need to pay for re-verification anyway, so on top of having to pay an extra $25 to revoke our cert, it makes sense to just find a better CA now.
[ link to this | view in chronology ]
Re: Disagree
I didn't even ask for free revocation, I was asking for leniency in the price as $2000 for revocation of all my certificates (*that I paid for*) is nothing short of a hostage situation.
[ link to this | view in chronology ]
Re: Re: Disagree
[ link to this | view in chronology ]
Re: Re: Re: Disagree
As the certificate holder, it is your job to not lose, or otherwise reveal your private key (not even to the CA - they only need your public key to create the cert).
Once the private key is lost of compromised, the certificate's usefulness is greatly diminished, and therefore should be revoked. This is not the CA's fault, it is generally considered the fault of the key holder.
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
However, as the heartbleed bug demonstrates, there are a huge number of reasons the certificate could be rendered untrustworthy that are not the fault of the key holder.
This isn't a matter of fault, anyway. This is a matter of being socially responsible. Also, revoking keys is not an expensive operation, so it's not like doing the at no charge would present a serious hardship.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Disagree
They have taken the stance that it is the 'fault' of the software choice, and therefore should not be entitled to any special circumstances.
However, there's nothing specifically insecure about the certificate, but rather, the private key that was used to create it may have been compromised.
That was my clarification - StartCom, nor their certs are at fault here - but they are certainly taking advantage of the situation.
[ link to this | view in chronology ]
Re: Re: Re: Disagree
[ link to this | view in chronology ]
Re: Disagree
If they don't want to cancel the certificates, how about they pay the damage this is about to cause?
[ link to this | view in chronology ]
Re: Re: Disagree
How do they endanger everyone useing the internet? At worst they endanger the sites and users of the sites the certificates are for. That is not "everyone who uses the internet".
[ link to this | view in chronology ]
Re: Disagree
When it comes to certificate revocation, the deserve a TON of vilification for it. Certificate revocation is central to maintaining the trust chain. Being able to do this is more important than being able to issue the certificate in the first place. This is an act that there should never be a charge for, for the good of the entire security ecosystem.
"They provide free certs and deserve thanks for that. They charge to revoke certs, that's how pay services work."
That's an immoral way to go about it, for the reason I state above. They should charge for the issuing but not the revocation. To reverse that is harmful for everyone whether they use this company's services or not.
This company's behavior is not just scummy, it is incredibly irresponsible. They need to be drummed out of this business entirely. Period.
[ link to this | view in chronology ]
Re: Re: Disagree
When it was found that a large number of their certs were signed with weak debian keys (remember that fiasco?) they automatically revoked them.
And yet, here we are with another situation where we clearly need to revoke a large number of certs "just to be sure", and they're capitalizing on it this time around.
[ link to this | view in chronology ]
Re: Re: Re: Disagree
However, while I think they should be revoking certs for free, it is a different situation because they didn't make the problem.
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Disagree
So, yes, they used to do this for free, and then realized at some point that they could capitalize on it.
Detestable.
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
Can you imagine what the world would be like if everyone thought that way about everything?
"We didn't create ! Therefore we refuse to do anything to improve the situation, even though we have the power to do so at no cost or hardship to ourselves and are best suited for the task!"
It's only fair, right?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Disagree
So, what's your point? IT's (sic) not just them.
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
Can you imagine what the world would be like if everyone thought that way about everything?
"We didn't create (insert any problem here)! Therefore we refuse to do anything to improve the situation, even though we have the power to do so at no cost or hardship to ourselves and are best suited for the task!"
It's only fair, right?
Edit: Stupid HTML tag thingy with > and < ate part of my post.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Disagree
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Disagree
Forward compatibility. If it were to become an allowed tag sometime in the future, people would start using the tag on their websites. Display is considered better if it simply ignores tags that it doesn't understand rather than polluting the text with a bunch of tags that weren't supposed to be directly visible in the first place.
Example: if a designer wanted some thing to look like this:
This is some bold and italic text!
but it was displayed in a browser that didn't understand the bold tag, it would make more sense to show
This is some bold and italic text!
Rather than
This is some bold and italic text!
The latter is just cluttered up with commands that get in the way of the actual content.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Disagree
[ link to this | view in chronology ]
Re: Re: Re: Disagree
Try "all of them that were issued in the last two years" (those that are still active anyway). And that doesn't fix the problem - which is the "client's" use of a broken version of encryption software, which is completely out of their hands, and could still happen again if (say) my cert was revoked, i obtain a new one right now, but continue using the broken openssl version! StartSSL has no way of knowing if a client leaked their SSL key.
But they should absolutely revoke it for free, waive the fee if the client acknowledges having used the broken openssl version, or if necessary at least defer the fee until the client requests a reissue. And add a new opt-in checkbox asserting that the client has verified they are no longer vulnerable to heartbleed (and similar issues - i doubt i've seen the last one one of this kind in my lifetime).
But I'm starting to see a whole host of counter arguments and corner cases, so really the only simple and honorable thing to do is not charge for revocation. The real solution, as Moxie Marlinspike pointed out years ago, is to move away from the CA model.
[ link to this | view in chronology ]
Re: Re: Disagree
It's sorta like the old saying:
So they are taking advantage of the fact that takeoffs are optional, so they are free. But since once you've taken off you HAVE to land at asome point, they are gonna charge you for that.
Sad, but effective, way to do business.
[ link to this | view in chronology ]
Re: Re: Re: Disagree
Once.
[ link to this | view in chronology ]
Re: Re: Re: Re: Disagree
Once.
Assuming you don't have a steady supply of suckers that for one reason or another haven't heard how your business models work. A large enough market with enough churn can keep a lot of abuses going for a surprisingly long time.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Disagree
That is, sadly, true. Still - once screwed like that you'd rather not return. So it will not be a returning business, and as the pool of potential clients diminishes - so would their business. The story is big, so there will be just a few clueless noobs there.
As to the uninformed suckers - they'll have what they want for being uninformed suckers. No sympathy here...
[ link to this | view in chronology ]
Re: Disagree
Everyone within the chain of trust has a responsibility to protect it backed by the ability of the chain to revoke their authority, which is the only thing keeping the chain functional. To hinder necessary remediation is playing with fire. Instead they should be revoking the certificates and charging for the re-issuing of certificates that had to be revoked due to being compromised. They would still need to weigh in customer loyalty when considering their pocket book, but then they would at least be correct in pointing out the difference in responsibilities.
[ link to this | view in chronology ]
Re: Disagree
[ link to this | view in chronology ]
Re: Disagree
[ link to this | view in chronology ]
Easy solution
[ link to this | view in chronology ]
Re: Easy solution
[ link to this | view in chronology ]
Re: Easy solution
[ link to this | view in chronology ]
Re: Re: Easy solution
So far I haven't run into any sites that use them, so I guess that's good.
[ link to this | view in chronology ]
trust
but as a individual I know that startssl.com allows untrustworth certificates to exist, and endorses their existence, the are the ones not revoking compromised certificates.
so the cannot be a trusted certificate authority, my software will be adjusted accordingly
[ link to this | view in chronology ]
Typical Corporation
[ link to this | view in chronology ]
The purpose of a cert is trust and startssl has destroyed that supposed trust by delaying the ability to secure the net. I don't need nor want to trust anyone with this sort of attitude.
Ultimately in the end it is my computer and I determine what will or will not run on it. By it's lack of concern over the net security it has envoked a lack of concern on my part for it's supposed function.
[ link to this | view in chronology ]
Re:
Me being pedantic here; but SSL certs don't "run". They might (metaphorically) "fly"....
[ link to this | view in chronology ]
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenan ce/
Section 2, dot 2.
CAs must revoke Certificates that they have issued upon the occurrence of any of the following events:
The CA obtains reasonable evidence that the subscriber�s private key (corresponding to the public key in the certificate) has been compromised or is suspected of compromise (e.g. Debian weak keys), or that the certificate has otherwise been misused;
[ link to this | view in chronology ]
Re:
https://bugzilla.mozilla.org/show_bug.cgi?id=994478
[ link to this | view in chronology ]
Re: Re:
Speaking of, I noticed that Debian has already pushed out the security fix for this in their repository. Update immediately.
[ link to this | view in chronology ]
NSA to save the day.
[ link to this | view in chronology ]
Something for the weekend...
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Possible workaround
While I'm not surprised at StartSSL's response (the owner, Eddy Nigg, isn't the most amicable or reasonable person - especially when questioning their CA policies), things like this warrant special treatment to avoid a public relations nightmare. The simplest solution is to write a script to revoke all certificates and send an e-mail to website operators letting them know about the situation and how to reissue their certificate(s). Yeah, some people might be annoyed, but I'm sure there are a number of people out there who haven't even heard about Heartbleed who need to know.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
If you can't revoke a certificate, it's not secure.
Revocation of any certificate is a fundamental and required property of any certificate. If you can't revoke it, it's NOT secure.
If you're not providing revocable certificates, you're providing anti-security snake-oil. You are intentionally damaging your users' security.
If a certificate cannot be trivially revoked for free by the person who requested it, it is hollow and false and anti-secure.
Any company that provides a certificate that cannot be revoked is actively harming your security, never improving it. They should be removed from "trusted" CA lists, and you should petition the manufacturer or your browser or other software to remove them.
If any CA allows any certificate to be accepted when you have asserted that it is not valid, and proved that you own the certificate with your CSR or private key, they are no longer trustable and should be removed from any trusted CA list. (As a side-effect, this will mean they have no more business, so it is in their best interest to allow users to revoke the certificates they have generated.)
StartSSL has failed in all of these basic aspects of security. I need to go elsewhere.
[ link to this | view in chronology ]
Revocation certificate is your "safeword"
If your certification authority doesn't IMMEDIATELY and UNCONDITIONALLY, ALWAYS, stop hurting you when your assert your revocation rights, (your safeword,) then they cannot any longer be trusted and are just butt-assaulting you.
This is what StartSSL is doing by refusing to let you revoke any certificate that you gave them permission to issue. They're butt-assaulting their customers, and letting anyone on the internet do so as well, even though they've been asked to stop.
[ link to this | view in chronology ]
whiny bastages
[ link to this | view in chronology ]
Re: whiny bastages
StartSSL is providing certs for free but charges money to mitigate disasters. This motivates cert owners not to mitigate disasters and to keep using compromised certs, reducing security for the SSL initiators, who should be the CA's primary concern. If StartSSL learns about a compromised cert, they do nothing until unless they get paid. They are not acting responsibly. They are taking the SSL initiators hostage, keeping the compromise to themselves, allowing MITM attacks to take place.
It doesn't matter if StartSSL makes an exception for heartbleed. This policy is wrong and insecure and from the perspective of SSL initiators, the only correct course of action is to remove StartSSL from trusted CAs. As an initiator, how do I know that a cert is valid if the CA is known to keep disasters a secret?
[ link to this | view in chronology ]
Awful
[ link to this | view in chronology ]
The result of cheap SSL providers
[ link to this | view in chronology ]