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:
Filed Under: heartbleed, openssl, revocation, secure certs, security, startssl, vulnerability
Companies: startcom
Comments on “Shameful Security: StartCom Charges People To Revoke SSL Certs Vulnerable To Heartbleed”
Time to return the favor I'd say
If they’re so greedy that they’re charging people to fix a problem this huge, then I’d say it’s time for everyone who was using them to swap to another company, even if it does cost a bit more.
When I hit you up on twitter about this, it was because the Dutch pirate party was having issues over it. Thing is, the Dutch PP doesn’t even use the free certs, they pay for them. And STartSSL wants something like $1200+ to revoke them.
Re: Re:
Here’s the thing about it on the dutch pirate site (it is in dutch though) http://www.piratenpartij.nl/blog/argure/https-foutmeldingen-piratenpartij
What makes this worse...
…is that they refuse to do this for paid customers as well. If you shell out $119,80 a year to StartSSL for validation so you can generate multiple certificates; you still have to pay the full handling fee *per certificate*, costing upwards of hundreds of dollars.
My e-mails with StartSSL:
Re: What makes this worse...
exactly, on the dutch link above you’ll see they’re looking at between $1200 and $1400
Yep... finding a new CA
As an open source project, we have used StartCom’s class 2 wildcard certs because they’re so ridiculously cheap compared to most of the CAs out there.
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.
Re: Yep... finding a new CA
No need to pay for revocation.
Just move over to another CA and let the old ones expire.
To bad DNSSEC and DANE are not production-ready yet.
Re: Re: Yep... finding a new CA
“Just move over to another CA and let the old ones expire.”
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.
Re: Re: Re: Yep... finding a new CA
Correct, we still have to revoke the old certificate to be sure it will not be used within the next two months along with a potentially pilfered private key.
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.
Re: Re: Re:2 Yep... finding a new CA
Yes, I should have put a disclaimer that just ignoring the old certificate might present a reasonable risk for your particular project (without a security audit, nobody can really know). I was really just chiming in so that people don’t think this is a generally risk-free solution in all circumstances.
“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.
Re: Re: Re:3 Yep... finding a new CA
Yes, in FOSS, doing the “right thing” is generally the only way you earn respect.
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.
Re: What CA offers free certs to FOSS projects?
What CA offers free certs to FOSS projects?
Re: Re: What CA offers free certs to FOSS projects?
I normally wouldn’t advertise something like this, but since I represent a FOSS project, and we did successfully obtain a cert from them, I don’t mind sharing the link I found via google search:
https://www.globalsign.com/ssl/ssl-open-source/
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.
Re: startssl.com declares intention to commit corporate suicide
When the Morris Worm hit, about 25 years ago, we all put aside our differences and our squabbles to patch things up, but we didn’t learn our lesson.
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.
Re: Re: startssl.com declares intention to commit corporate suicide
When Rust, a programming language designed to prevent such vulnerabilities, was first made public I saw many programmers saying they didn’t see the point of the language. Most programmers don’t give a fuck about security. That’s why security sucks.
Re: Re: startssl.com declares intention to commit corporate suicide
Re: Re: startssl.com declares intention to commit corporate suicide
All the interpreters within each of those languages you mentioned will be written in C/C++.
So I don’t really get your point?
I don’t get charging to revoke a cert to begin with. The point of revoking a cert is because it is no longer being used and has the potential to be fraudulently used. Refusing to revoke a certificate damages the whole trust chain.
Re: Re:
It’s an additional burden on the verification system.
Re: Re: Re:
They are in the business of establishing trust. Anything that damages that trust should be mitigated regardless of the burden and written off as cost of doing business. After all, without that trust, they have no business.
Re: Re: Re: Re:
How the fuck do you expect Eddy Nigg to mitigate the NSA?
How the fuck.
Re: Re: Re:2 Re:
Well, anything within the CA’s power, which revocation is.
Congrats @StartSSL, you just killed your company. No sysadmin worth his salt would risk doing business with you now.
Disagree
It would be really swell for them to provide their services for free but I hardly agree that they deserve vilification when they don’t. They provide free certs and deserve thanks for that. They charge to revoke certs, that’s how pay services work. Now people who got something valuable for free are complaining that they have to pay for a different thing that is valuable? I say pay the company. That’s how businesses work. If it’s not worth it to you then don’t pay them.
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.
Re: Disagree
I think you misunderstand.
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.
Re: Re: Disagree
“It’s the PAID certs that they charge to revoke.”
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.
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.
Re: Re: Re:2 Disagree
“we should admit that the whole damn mess is b0rked.”
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.
Re: Re: Re:3 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.”
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.
Re: Re: Re:4 Disagree
?It’s only a flesh wound!?
Re: Re: Re:4 Disagree
“And also the fact that TLS cert revocation is more a baroque joke at the internet’s expense than a reliable mechanism.”
Absolutely true. How certificate revocation is handled is messed up and a major (perhaps the major) problem with how the trust chain is maintained.
Re: Re: Re: Disagree
Indeed, it seems the article is misleading. I guess the assumption is that the free certs are what people are being charged to revoke… but that’s untrue.
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.
Re: Disagree
I never used a free certificate from StartCom – I pay them $119.80 a year – yet they still refuse to revoke my certificates.
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.
Re: Re: Disagree
Wait a minute didn’t you pay them for a secure certificate…shouldn’t you be asking for a refund on the basis the certificate isn’t secure?
Re: Re: Re: Disagree
There’s nothing specific about the certificate that guarantees security, only identity.
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.
Re: Re: Re:2 Disagree
“This is not the CA’s fault, it is generally considered the fault of the key holder.”
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.
Re: Re: Re:3 Disagree
Oh, I agree – in this case, they should consider it a special situation.
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.
Re: Re: Re: Disagree
The certificate is fine. If the site using the certificate used OpenSSL (the software with the “bug”) THEN the site isn’t secure. But the only way to re-secure the site is update the SSL software and revoke the old certificate then get a new one.
Re: Disagree
I’d agree with you, but for the fact that by not cancelling the affected certificates, they endanger everyone who uses the internet.
If they don’t want to cancel the certificates, how about they pay the damage this is about to cause?
Re: Re: Disagree
Come again?
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”.
Re: Disagree
“I hardly agree that they deserve vilification when they don’t”
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.
Re: Re: Disagree
A double standard too…
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.
Re: Re: Re: Disagree
Yes, because that was a problem of their own making.
However, while I think they should be revoking certs for free, it is a different situation because they didn’t make the problem.
Re: Re: Re:2 Disagree
How was the use of weak Debian-based keys their problem? These were keys provided by individuals using Debian-based distros to generate them.
Re: Re: Re:3 Disagree
I found clarification of this in their forums btw – apparently when the weak Debian key issue occurred, StartCom was still revoking certs for free – they have since changed their policies.
So, yes, they used to do this for free, and then realized at some point that they could capitalize on it.
Detestable.
Re: Re: Re:2 Disagree
The problem of Heartbleed may not be of their own making, but the problem of them endorsing potentially compromised certificates is.
Re: Re: Re:2 Disagree
“it is a different situation because they didn’t make the problem.”
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?
Re: Re: Re:3 Disagree
Obviously you haven’t been paying attention to those EULA’s, ToS, or any other screen or print that concerns IT. Try reading this crap sometime. IT (sic) may not function correctly if at all, IT’s (sic) never their fault since you bought IT (sic)knowing this, IT’s (sic) damages are your problem not theirs, and lastly IT’s (sic) forbidden to use it anywhere near a regulated environment (medical, nuke power plant, airport).
So, what’s your point? IT’s (sic) not just them.
Re: Re: Re:2 Disagree
“it is a different situation because they didn’t make the problem.”
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.
Re: Re: Re:3 Disagree
Speaking of having text eaten, why does it do that? If the text between an > and an < isn’t an allowed HTML tag, it should leave the text alone and just post it as is.
Re: Re: Re:4 Disagree
Speaking of having text eaten, why does it do that? If the text between an > and an < isn’t an allowed HTML tag, it should leave the text alone and just post it as is.
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.
Re: Re: Re:5 Disagree
Still though, it seems like a rather simple if/else proposition. If text between a > and an < isn’t one of the predefined options, like italic/bold/etc, don’t eat my damn text you evil machine lol! I’m not a programmer, but I highly doubt the text I had between > and < is something that will ever become a real tag for heavens sake. If one doesn’t want to limit the code to just the currently available HTML options because new ones might be introduced in the future (hard to see what they would be since the basics are pretty well covered) then perhaps the answer would be to look at the total number of characters between the > and
Re: Re: Re: Disagree
Re: Re: Disagree
I agree with this. They should only be charging for issuing, not revocationn.
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.
Re: Re: Re: Disagree
“Sad, but effective, way to do business”
Once.
Re: Re: Re:2 Disagree
“Sad, but effective, way to do business”
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.
Re: Re: Re:3 Disagree
“A large enough market with enough churn can keep a lot of abuses going for a surprisingly long time.”
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…
Re: Disagree
The thing that both the article and you miss is that being irresponsible with the chain of trust in this manner, especially when they have every reason to believe that the certs that are pending revocation are compromised, could cost them their own certification. They are beholden to the next level up the cert chain, and if any level is revoked, all the bad certs go away.
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.
Re: Disagree
The question isn’t really whether or not they deserve to be vilified. The question is whether or not you should trust the certs they issue. Making it hard for people to revoke the certs means people will be hesitant to revoke bad certs. That means their certs should not be trusted.
Re: Disagree
The situation is like selling drinking water in time of, say, flood. Yes, you can ask for $10, $20, even $100 per bottle, and you will get it. After all – should you deserve vilification for not providing it for free? It might even be a recurring business. At least as long as the flood lasts.
Easy solution
Remove StartCom from your list of trusted root CAs. Now their “free” product is worth what you paid (nothing).
Re: Easy solution
Given how they respond to this problem, which most of their customers were victims of themselves, I wouldn’t be surprised if a few major browser vendors blackhole StartCom…
Re: Easy solution
A thousand times this. Fortunately, their root CA never was in my trusted root list for my own servers. I have now started the process to have it removed from the trusted root list at my workplace.
Re: Re: Easy solution
Now that our project has moved away from a StartCom cert, I have also removed them from all my own machines.
So far I haven’t run into any sites that use them, so I guess that’s good.
trust
the certificate is a unit of 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
Typical Corporation
Typical corporate short term fiscal thinking, trying to get their money now and screw what comes next. A lot has been destroyed by the selfish morons at the helm. I’d compare them to hordes of locusts but that would be an insult to the bug.
Just as soon as I finish with this post, I will revoke the certificate on my computer. I don’t have to care if startssl revokes or doesn’t revoke willingly. Mine will simply no longer allow it to run. Whatever else might be supported by this cert company will also go down.
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.
Re: Re:
Who wants to file the bug for removal from Mozilla?
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
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;
Re: Re:
Screw it, I did it myself. I don’t want this CA in my browser.
https://bugzilla.mozilla.org/show_bug.cgi?id=994478
Re: Re: Re:
You can also remove the certificate from your browser yourself. You don’t have to wait for the distro to do it.
Speaking of, I noticed that Debian has already pushed out the security fix for this in their repository. Update immediately.
NSA to save the day.
Man, I think we should trust the NSA to save the day. After all, Security is their Middle Name.
Something for the weekend...
Nice to know why email accounts I have list subscribed are headed for the stratosphere. No, I really haven’t looked. And no, in my downtime the internet can turn into molten slag for all I care. Wait, what?
Removed their CA cert from my browsers, and shared recommendation and instructions with all my friends to do the same.
Re: Re:
Ditto.
Possible workaround
If you use the free StartSSL certs and don’t mind some minimal hassle, you can temporarily get around the StartSSL revocation limitations by choosing an alternate subdomain until the original cert expires. For example, if you have a http://www.whatever.com domain cert, you can temporarily use ssl.whatever.com and their system will issue you a new cert right away – for free. The cert will be signed for both ssl.whatever.com and whatever.com. This approach works fairly well if you rely on whatever.com instead of http://www.whatever.com. Note that this won’t stop a MITM attack where someone got the private key via Heartbleed, but MITM attacks against the general population are pretty difficult to pull off (MITM is generally a focused attack against an individual or a specific group), so this approach creates an effective revocation without having to pay for it as a stop-gap until the original cert expires. It isn’t a real revocation, but it is a potentially viable workaround, especially if there are only a couple of months left on the current cert.
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.
Every browser vendor should blacklist all their certs then.
If you can't revoke a certificate, it's not secure.
A fundamental and necessary and obvious property of a security certificate is that it must must be revocable at any time, without providing reason, without cost, by the person who generated the certificate request.
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.
Revocation certificate is your "safeword"
To use an analogy from the bondage scene, when you create a security certficate, you need to create a revocation agreement, or in other words, your “safeword.” When you say your safeword, your certification authority HAS TO STOP, immediately, pretending that it’s okay to keep hurting you.
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.
whiny bastages
Revoking uses completely different technology than issuing certs, and the system fundamentally doesn’t scale well for revocations. Startcom is providing economic incentive to not abuse the revocation process beyond its ability to scale. Complain all you want about how the system SHOULD work, that’s doesn’t change how it does work. Even with the paid revocations, the pricing model there is still far better than anywhere else for me. I’m willing to do the right thing and revoke certs even though it costs me money. All the whining here isn’t about doing the right thing, it’s about having someone else subsidize site owners for doing so. Annoying? yes. Showstopper? no.
Re: whiny bastages
I don’t have a problem with a business model or pricing system itself. I do have a problem with it’s security implications. The primary function of a CA is providing security to SSL initiators. Those who initiate SSL connections and hope that if a cert is signed by this CA, that they can trust the connection.
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?
Awful
If consumers work together, more companies like this will go away. It’s unfortunate how many good people have to deal with bad companies. And, we know exactly how frustrating it is.
The result of cheap SSL providers
Unfortunately, this type of activity has become the norm for the low end Certificate Authority industry because of demand for near $0 pricing. Reality is that maintaining a legitimate PKI infrastructure costs money and will always be compromised by low end providers like StartCom.