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:

Yes, this is part of StartCom’s business model. Free certs, pay to revoke (Update: but that doesn’t explain why they’re doing this for paying customers too…). But this is clearly a case where that model should be suspended to keep the internet safe. The amount of ill-will this move is generating is pretty clear. Furthermore, it highlights what a bullshit claim it is that its goal is to better protect communications. If that were true, it would allow emergency revocations for an issue like Heartbleed.

Filed Under: , , , , , ,
Companies: startcom

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Shameful Security: StartCom Charges People To Revoke SSL Certs Vulnerable To Heartbleed”

Subscribe: RSS Leave a comment
84 Comments
Anonymous Coward says:

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.

John Fenderson (profile) says:

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.

Anonymous Coward says:

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.

John Fenderson (profile) says:

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.

Anonymous Coward says:

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.

Rich Kulawiec (profile) says:

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.

Mason Wheeler (profile) says:

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:

A consequence of this principle [designing a language with checks against buffer overruns built in] is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to?they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

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.

Anonymous Coward says:

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.

beltorak (profile) says:

Re: Re: startssl.com declares intention to commit corporate suicide

A quarter-century later, people are still getting hacked by buffer overruns, including Heartbleed….

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.

atural says:

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.

atural says:

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.

John Fenderson (profile) says:

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.

Adam Williamson (user link) says:

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.

Anonymous Coward says:

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.

Argure (user link) says:

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.

Anonymous Coward says:

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.

John Fenderson (profile) says:

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.

Anonymous Coward says:

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.

John Fenderson (profile) says:

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.

Anonymous Coward says:

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.

Eldakka (profile) says:

Re: 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.

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.

Anonymous Coward says:

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.

Depressingly Annonymous says:

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?

JackOfShadows (profile) says:

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.

Depressingly Annonymous says:

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.

Anonymous Coward says:

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.

Dyslexicly Anunimsa (Apparently LOL) says:

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

beltorak (profile) says:

Re: Re: Re: Disagree

where we clearly need to revoke a large number of certs “just to be sure”

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.

Eldakka (profile) says:

Re: Re: Disagree

I agree with this. They should only be charging for issuing, not revocationn.

It’s sorta like the old saying:

Every takeoff is optional, every landing is mandatory

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.

Anonymous Coward says:

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.

antymat says:

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…

Brazenly Anonymous says:

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.

Anonymous Coward says:

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.

NUXI (profile) says:

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;

Kes says:

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.

Alan Eliasen (user link) says:

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.

Bondage Joe says:

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.

ED Fochler (profile) says:

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.

Mike Ward (profile) says:

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?

Add Your Comment

Your email address will not be published.

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...