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.

Reader Comments (rss)

(Flattened / Threaded)

  •  
    icon
    That One Guy (profile), Apr 9th, 2014 @ 12:04pm

    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.

     

    reply to this | link to this | view in chronology ]

  •  
    icon
    Andrew Norton (profile), Apr 9th, 2014 @ 1:06pm

    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.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Argure, Apr 9th, 2014 @ 1:09pm

    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:

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Anonymous Coward, Apr 9th, 2014 @ 1:25pm

    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.

     

    reply to this | link to this | view in chronology ]

    •  
      identicon
      Anonymous Coward, Apr 10th, 2014 @ 1:32am

      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.

       

      reply to this | link to this | view in chronology ]

      •  
        icon
        John Fenderson (profile), Apr 10th, 2014 @ 8:24am

        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.

         

        reply to this | link to this | view in chronology ]

        •  
          identicon
          Anonymous Coward, Apr 10th, 2014 @ 11:09am

          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.

           

          reply to this | link to this | view in chronology ]

          •  
            icon
            John Fenderson (profile), Apr 10th, 2014 @ 2:43pm

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

             

            reply to this | link to this | view in chronology ]

            •  
              identicon
              Anonymous Coward, Apr 12th, 2014 @ 5:40pm

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

               

              reply to this | link to this | view in chronology ]

    •  
      identicon
      Dan, Apr 10th, 2014 @ 5:32pm

      What CA offers free certs to FOSS projects?

      What CA offers free certs to FOSS projects?

       

      reply to this | link to this | view in chronology ]

  •  
    identicon
    Rich Kulawiec, Apr 9th, 2014 @ 1:27pm

    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.

     

    reply to this | link to this | view in chronology ]

    •  
      icon
      Mason Wheeler (profile), Apr 9th, 2014 @ 2:17pm

      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.

       

      reply to this | link to this | view in chronology ]

      •  
        identicon
        Anonymous Coward, Apr 9th, 2014 @ 3:50pm

        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.

         

        reply to this | link to this | view in chronology ]

      •  
        icon
        beltorak (profile), Apr 9th, 2014 @ 8:39pm

        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.

         

        reply to this | link to this | view in chronology ]

      •  
        identicon
        Anonymous Coward, Apr 11th, 2014 @ 4:54am

        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?

         

        reply to this | link to this | view in chronology ]

  •  
    identicon
    Anonymous Coward, Apr 9th, 2014 @ 1:37pm

    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.

     

    reply to this | link to this | view in chronology ]

    •  
      identicon
      Anonymous Coward, Apr 9th, 2014 @ 1:41pm

      Re:

      It's an additional burden on the verification system.

       

      reply to this | link to this | view in chronology ]

      •  
        identicon
        Anonymous Coward, Apr 9th, 2014 @ 2:05pm

        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.

         

        reply to this | link to this | view in chronology ]

  •  
    identicon
    Zonker, Apr 9th, 2014 @ 1:40pm

    Congrats @StartSSL, you just killed your company. No sysadmin worth his salt would risk doing business with you now.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    atural, Apr 9th, 2014 @ 1:41pm

    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.

     

    reply to this | link to this | view in chronology ]

    •  
      identicon
      Anonymous Coward, Apr 9th, 2014 @ 1:45pm

      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.

       

      reply to this | link to this | view in chronology ]

      •  
        identicon
        atural, Apr 9th, 2014 @ 2:00pm

        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.

         

        reply to this | link to this | view in chronology ]

        •  
          identicon
          Anonymous Coward, Apr 9th, 2014 @ 2:05pm

          Re: Re: Re: Disagree

          … find a new cert auth…

          Find a new CA who isn't in bed with NSA.

          Maybe —instead— we should admit that the whole damn mess is b0rked.

           

          reply to this | link to this | view in chronology ]

          •  
            icon
            John Fenderson (profile), Apr 9th, 2014 @ 3:01pm

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

             

            reply to this | link to this | view in chronology ]

            •  
              identicon
              Adam Williamson, Apr 9th, 2014 @ 4:59pm

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

              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.

               

              reply to this | link to this | view in chronology ]

              •  
                identicon
                Anonymous Coward, Apr 9th, 2014 @ 5:20pm

                Re: Re: Re: Re: Re: Re: Disagree

                While the system has some flaws…
                And also the fact that…

                It's only a flesh wound!

                 

                reply to this | link to this | view in chronology ]

              •  
                icon
                John Fenderson (profile), Apr 10th, 2014 @ 8:27am

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

                Absolutely true. How certificate revocation is handled is messed up and a major (perhaps the major) problem with how the trust chain is maintained.

                 

                reply to this | link to this | view in chronology ]

        •  
          identicon
          Anonymous Coward, Apr 9th, 2014 @ 2:06pm

          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.

           

          reply to this | link to this | view in chronology ]

    •  
      identicon
      Argure, Apr 9th, 2014 @ 1:46pm

      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.

       

      reply to this | link to this | view in chronology ]

      •  
        identicon
        Anonymous Coward, Apr 9th, 2014 @ 2:09pm

        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?

         

        reply to this | link to this | view in chronology ]

        •  
          identicon
          Anonymous Coward, Apr 9th, 2014 @ 2:27pm

          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.

           

          reply to this | link to this | view in chronology ]

          •  
            icon
            John Fenderson (profile), Apr 9th, 2014 @ 2:47pm

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

             

            reply to this | link to this | view in chronology ]

            •  
              identicon
              Anonymous Coward, Apr 9th, 2014 @ 2:54pm

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

               

              reply to this | link to this | view in chronology ]

        •  
          icon
          Ben (profile), Apr 9th, 2014 @ 2:31pm

          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.

           

          reply to this | link to this | view in chronology ]

    •  
      identicon
      Anonymous Coward, Apr 9th, 2014 @ 2:07pm

      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?

       

      reply to this | link to this | view in chronology ]

      •  
        icon
        Eldakka (profile), Apr 9th, 2014 @ 8:47pm

        Re: Re: Disagree

        they endanger everyone who uses the internet.
        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".

         

        reply to this | link to this | view in chronology ]

    •  
      icon
      John Fenderson (profile), Apr 9th, 2014 @ 2:42pm

      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.

       

      reply to this | link to this | view in chronology ]

      •  
        identicon
        Anonymous Coward, Apr 9th, 2014 @ 2:46pm

        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.

         

        reply to this | link to this | view in chronology ]

        •  
          icon
          Eldakka (profile), Apr 9th, 2014 @ 8:49pm

          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.

           

          reply to this | link to this | view in chronology ]

          •  
            identicon
            Anonymous Coward, Apr 9th, 2014 @ 10:06pm

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

             

            reply to this | link to this | view in chronology ]

            •  
              identicon
              Anonymous Coward, Apr 12th, 2014 @ 1:36pm

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

               

              reply to this | link to this | view in chronology ]

          •  
            identicon
            Anonymous Coward, Apr 10th, 2014 @ 5:32am

            Re: Re: Re: Re: Disagree

            The problem of Heartbleed may not be of their own making, but the problem of them endorsing potentially compromised certificates is.

             

            reply to this | link to this | view in chronology ]

          •  
            identicon
            Depressingly Annonymous, Apr 11th, 2014 @ 8:07am

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

             

            reply to this | link to this | view in chronology ]

            •  
              icon
              JackOfShadows (profile), Apr 11th, 2014 @ 3:22pm

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

               

              reply to this | link to this | view in chronology ]

          •  
            identicon
            Depressingly Annonymous, Apr 11th, 2014 @ 8:09am

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

             

            reply to this | link to this | view in chronology ]

            •  
              identicon
              Depressingly Annonymous, Apr 11th, 2014 @ 8:12am

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

               

              reply to this | link to this | view in chronology ]

              •  
                identicon
                Anonymous Coward, Apr 11th, 2014 @ 8:38am

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

                 

                reply to this | link to this | view in chronology ]

                •  
                  identicon
                  Dyslexicly Anunimsa (Apparently LOL), Apr 11th, 2014 @ 11:07am

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

                   

                  reply to this | link to this | view in chronology ]

        •  
          icon
          beltorak (profile), Apr 9th, 2014 @ 8:55pm

          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.

           

          reply to this | link to this | view in chronology ]

      •  
        icon
        Eldakka (profile), Apr 9th, 2014 @ 8:52pm

        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.

         

        reply to this | link to this | view in chronology ]

        •  
          identicon
          antymat, Apr 10th, 2014 @ 11:18pm

          Re: Re: Re: Disagree

          "Sad, but effective, way to do business"
          Once.

           

          reply to this | link to this | view in chronology ]

          •  
            identicon
            Anonymous Coward, Apr 11th, 2014 @ 5:21am

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

             

            reply to this | link to this | view in chronology ]

            •  
              identicon
              antymat, Apr 12th, 2014 @ 3:03am

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

               

              reply to this | link to this | view in chronology ]

    •  
      identicon
      Brazenly Anonymous, Apr 9th, 2014 @ 8:47pm

      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.

       

      reply to this | link to this | view in chronology ]

    •  
      icon
      PrometheeFeu (profile), Apr 10th, 2014 @ 3:59pm

      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.

       

      reply to this | link to this | view in chronology ]

    •  
      identicon
      antymat, Apr 10th, 2014 @ 11:16pm

      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.

       

      reply to this | link to this | view in chronology ]

  •  
    identicon
    pegr, Apr 9th, 2014 @ 1:50pm

    Easy solution

    Remove StartCom from your list of trusted root CAs. Now their "free" product is worth what you paid (nothing).

     

    reply to this | link to this | view in chronology ]

    •  
      identicon
      Anonymous Coward, Apr 9th, 2014 @ 1:57pm

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

       

      reply to this | link to this | view in chronology ]

    •  
      icon
      John Fenderson (profile), Apr 9th, 2014 @ 2:44pm

      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.

       

      reply to this | link to this | view in chronology ]

      •  
        identicon
        Anonymous Coward, Apr 12th, 2014 @ 1:37pm

        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.

         

        reply to this | link to this | view in chronology ]

  •  
    identicon
    Anonymous Coward, Apr 9th, 2014 @ 2:19pm

    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

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Anonymous Coward, Apr 9th, 2014 @ 2:33pm

    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.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Anonymous Coward, Apr 9th, 2014 @ 2:48pm

    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.

     

    reply to this | link to this | view in chronology ]

  •  
    icon
    NUXI (profile), Apr 9th, 2014 @ 9:32pm

    Who wants to file the bug for removal from Mozilla?

    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;

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Capt ICE Enforcer, Apr 10th, 2014 @ 3:57am

    NSA to save the day.

    Man, I think we should trust the NSA to save the day. After all, Security is their Middle Name.

     

    reply to this | link to this | view in chronology ]

  •  
    icon
    JackOfShadows (profile), Apr 10th, 2014 @ 4:39am

    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?

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Anonymous Coward, Apr 10th, 2014 @ 4:12pm

    Removed their CA cert from my browsers, and shared recommendation and instructions with all my friends to do the same.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Kes, Apr 10th, 2014 @ 8:27pm

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

     

    reply to this | link to this | view in chronology ]

  •  
    icon
    toyotabedzrock (profile), Apr 10th, 2014 @ 9:22pm

    Every browser vendor should blacklist all their certs then.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Alan Eliasen, Apr 12th, 2014 @ 2:05am

    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.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    Bondage Joe, Apr 12th, 2014 @ 2:51am

    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.

     

    reply to this | link to this | view in chronology ]

  •  
    identicon
    ED Fochler, Apr 13th, 2014 @ 7:27am

    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.

     

    reply to this | link to this | view in chronology ]

    •  
      identicon
      Mike Ward, Apr 13th, 2014 @ 11:44am

      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?

       

      reply to this | link to this | view in chronology ]

  •  
    identicon
    Sht Lst, Apr 16th, 2014 @ 4:36pm

    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.

     

    reply to this | link to this | view in chronology ]


Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here
Get Techdirt’s Daily Email
Save me a cookie
  • Note: A CRLF will be replaced by a break tag (<br>), all other allowable HTML will remain intact
  • Allowed HTML Tags: <b> <i> <a> <em> <br> <strong> <blockquote> <hr> <tt>
Follow Techdirt
Advertisement
Essential Reading
Techdirt Reading List
Techdirt Insider Chat
Advertisement
Recent Stories
Advertisement
Support Techdirt - Get Great Stuff!

Close

Email This

This feature is only available to registered users. Register or sign in to use it.