Slashdot Mirror

← Back to Stories (view on slashdot.org)

Private Keys Stolen Within Hours From Heartbleed OpenSSL Site

Posted by samzenpus on from the that-didn't-take-long dept.

Billly Gates (198444) writes "It was reported when heartbleed was discovered that only passwords would be at risk and private keys were still safe. Not anymore. Cloudfare launched the heartbleed challenge on a new server with the openSSL vulnerability and offered a prize to whoever could gain the private keys. Within hours several researchers and a hacker got in and got the private signing keys. Expect many forged certificates and other login attempts to banks and other popular websites in the coming weeks unless the browser makers and CA's revoke all the old keys and certificates."

62 of 151 comments (clear)

  1. Even root CA certificates may be at risk. by Z00L00K · · Score: 3, Insightful

    Be aware that even the root CA certificates can be at risk right now, and that can really cause problems.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    1. Re:Even root CA certificates may be at risk. by mlts · · Score: 4, Informative

      Depends. A website's SSL key may be slurped up. However, a root CA key should be either kept on an offline machine or kept in a hardware security module where the key won't be divulged, ever... the module will sign a key, and that's it.

      I'm sure some places will have their root CA on an externally connected machine, then try to place blame, likely saying how insecure UNIX is (when it isn't any particular flavor of UNIX that is at fault.)

    2. Re:Even root CA certificates may be at risk. by gweihir · · Score: 4, Funny

      That is BS. Nobody sane installs a root certificate on productive network-connected hardware, unless they are terminally stupid. Oh, wait...

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Even root CA certificates may be at risk. by mysidia · · Score: 2

      You would not believe what VP's will force you to do to get their $20 million flagship project out the door and then quickly forgotten about after the guy that was forced to do it quits in disgust.

      Fraud that can get you in jail is not one of those things that some VP can force you to do.

      The CA has to be validated by third party auditors, before it can even be trusted. One of the aspects that must be audited is the governance of that CA and the policies and controls of the CA designed to ensure the CA operates only according to the policies, and that would include that no system admin or member of management is capable of bypassing the rules.

  2. https is dead by lougarou · · Score: 5, Funny

    For all practical purposes, https is dead. There is no way browsers will carry around the hundreds of thousands of possibly-stolen-so-unsafe certificates fingerprints (to consider these tainted/revoked). The only way forward is probably to move away to an incompatible protocol. And if possible, cure some of the X509 wrong ways.

    1. Re:https is dead by Anonymous Coward · · Score: 5, Insightful

      Nah, the browsers will just reset 'zero epoch' for SSL certificates they'll accept to ONLY accept certificates issued after some date post-exploit, and all major SSL vendors will likely reboot their intermediate keychains so there's only a handful of 'revocation' certificates that will actually be needed due to the tree-of-trust model: Anything in the chain gets revoked everything below it goes away.

      And yes, this means the folks that were Johnny on the Spot about reissuing their certs might have to re-issue them AGAIN due to fixing their issue so quickly, but that's honestly pretty minor compared to the huge swaths of forever-vulnerable sites that need to effectively have their SSL status revoked regardless of what they do or don't do.

      WolfWings, who hasn't logged into SlashDot in YEARS.

    2. Re:https is dead by Anonymous Coward · · Score: 2, Interesting

      What do you mean, punish? Free certificates for all. The other AC is spot on. This is a make or break moment for the CAs. Unless they ensure that all vulnerable keys can no longer be used, the CA model is terminally damaged. The only way to make sure that all clients reject all vulnerable certificates is to change the root certificates and issue new certificates to everybody. If neither the CA nor the browser makers take this admittedly drastic step, I predict extensions soonish which will reject certificates issued before 2014-04-08. Either way, all certificates will have to be replaced soon.

    3. Re:https is dead by Anonymous Coward · · Score: 2, Insightful

      It's only free if admin's time is free and CA's time is free. Issuing certificates is not something all CAs can simply do one-sidedly and automatically. I take it you never had to manage certificates, did you?

      Only a week passed and already most Internet users won't see a site that didn't take care of that. The wave of reissuing and revoking is still growing, so most of vulnerable certificates will disappear pretty soon.

      Meanwhile, you're talking about wasting billions on the off chance a site with a hundred users was interesting enough for someone who could and would effectively MITM it - note that while grabbing the key only takes luck and time, actually using it requires much more.

    4. Re:https is dead by jonwil · · Score: 3, Interesting

      The problem with replacing HTTPS is that you will need to maintain regular HTTPS for all those clients that cant upgrade to a newer browser. (which exposes web sites to these threats) And you have to convince browser and web server vendors to support the new HTTPS replacement.

      Google would probably do it (on desktop, ChromeOS, Android and its custom web/SSL server software) especially if it made it harder for the kind of man-in-the-middle-using-fake-certificates type attacks the NSA have been using (the ones that let the NSA serve up fake copies of popular web sites as a vector to infect other machines). Opera and others that use the Google rendering engine would probably use the Google support.

      Mozilla would probably do it if you could convince them that its not just going to be bloat that never gets used.

      Apache would probably support it via a mod_blah and if they dont, someone else would probably write one.

      Other FOSS browsers and servers (those that do HTTPS) would probably support it if someone wrote good patches.

      But good luck convincing commercial vendors like Microsoft and Apple to support a new protocol. And the Certificate Authorities would fight hard against anything that made them obsolete (which any new protocol really needs to do)

    5. Re:https is dead by Anonymous Coward · · Score: 2, Insightful

      Time for SHTTP. The useless certificate authorities can go and die in a dark hole. Your bank can send you their public key. For most places you wouldn't even need a password.
      OpenSSH is developed by competent people and it has virtually no preauthentication attack surface.

    6. Re:https is dead by asdf7890 · · Score: 2

      Your bank can send you their public key.

      That is the key problem with schemes that don't involve a CA. A bank will be sending me bits of paper anyway when I open a new account, the better ones will be sending me a fob for two-factor auth too in fact, so sending an extra bit of paper with "this is the fingerprint of our signing key, when your browser asks you to confirm a certificate make sure the signer finger-print matches this one" is no hardship. But what about sites that don't have any other comms channel with their users? How do they prove that they are who they say they are?

      There is also the problem of people simply clicking "OK" instead of checking the fingerprint which is what usually happens with SSH. If this is the case all you have assurance of is that the keys have not changed, not that the keys indicate you are definitely talking to the right server directly.

    7. Re:https is dead by marcello_dl · · Score: 2

      > But what about sites that don't have any other comms channel with their users?

      They never have been secure and they will never be, because an early enough MITM attack renders checksums, certificates, and certificate authorities potentially irrelevant. You got your certificates from the internet or from a preinstalled OS which has likely been vetted by some agency. Your packets travel along thanks to routers with closed source OS. Your cellphone is designed as to permit the modem to do what heartbleed did. And so on.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
  3. Oh, man, what a mess by 93+Escort+Wagon · · Score: 3, Interesting

    I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge. But, still, this proved it's possible.

    So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

    --
    #DeleteChrome
    1. Re:Oh, man, what a mess by sphealey · · Score: 4, Interesting

      From the linked site: "He sent at least 2.5 million requests over the course of the day." So, no rate limiters, anti-DDS protection, or other active countermeasures in operation. Reasonable for this challenge but not overly realistic.

      sPh

    2. Re:Oh, man, what a mess by heypete · · Score: 5, Insightful

      So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

      Netcraft actually has an interesting article about that very situation.

      Obviously, the CAs don't really have a choice in the matter, but I can't imagine they really have capacity issues in regards to the actual revoking/signing as that's all automated. If things get crazy busy, they can always queue things -- for most admins it doesn't really matter if the new cert is issued immediately or after 15 minutes.

      Human-verified certs like org-verified and EV certs might have a bit of delays, but domain-validated certs should be quick to reissue.

      Of course, revocation checking for browsers is really bad. Ideally, all browsers would handle revocation checking in real-time using OCSP and all servers would have OCSP stapling enabled (this way the number of OCSP checks scales as the number of certs issued, not the number of end-users). Stapling would help reduce load on CA OCSP servers and enable certs to be verified even if one is using a network that blocks OCSP queries (e.g. you connect to a WiFi hotspot with an HTTPS-enabled captive portal that blocks internet traffic until you authenticate; without stapling there'd be no way to check the revocation status of the portal).

      Also, browsers should treat an OCSP failure as a show-stopper (though with the option for advanced users to continue anyway, similar to what happens with self-signed certificates).

      Sadly, that's basically the opposite of how things work now. Hopefully things will change in response to Heartbleed.

    3. Re:Oh, man, what a mess by mysidia · · Score: 5, Informative

      pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

      Calm down. A majority of web servers are not vulnerable and never were. All in all... less than 30% of SSL sites need to revoke any keys.

      Some websites are running with SSL crypto operations performed by a FIPS140-2 hardware security module; these are not vulnerable, since OpenSSL doesn't have access to the private key stored in the server's hardware crypto token.

      Many web sites are running on Windows IIS. None of these servers are vulnerable.

      Plenty of web sites are running under Apache with mod_nss, instead of mod_ssl. None of the websites using the LibNSS implementation of SSL are vulnerable.

      Many web sites are running on CentOS5 servers with Redhat's openssl 0.9.x packages. None of these servers were ever vulnerable.

      Many web sites are running on CentOS6 servers, that had not updated OpenSSL above 1.0.0. These websites weren't vulnerable.

      Many websites are running behind a SSL offload load-balancer; instead of using OpenSSL. Many of these sites were not vulnerable.

    4. Re:Oh, man, what a mess by Vairon · · Score: 2

      All websites running under any publicly released version of SUSE Linux Enterprise Server using the distribution's openSSL package were not vulnerable to HeartBleed.

    5. Re:Oh, man, what a mess by Anonymous Coward · · Score: 2, Informative

      That's not how certificate signing requests work. The private key isn't handed over to the CA.

    6. Re:Oh, man, what a mess by hairyfeet · · Score: 2

      Showing yet again that there is a reason why I like Comodo when it comes to security when Comodo found out their certs were vulnerable thanks to heartbleed Comodo got on the ball replacing certs ASAP.

      No company is perfect, every company will fuck up now and then, but the nice thing about Comodo is when they see a problem they don't try to bury it or play the blame game. Instead they announce "here is the problem and here is what we are doing about it" and then they DO IT, no stalling or bullshitting. In the case of heartbleed as companies patch their sites they can get a fresh key, no muss no fuss.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    7. Re:Oh, man, what a mess by Anonymous Coward · · Score: 2, Informative

      I believe the key point you made there is that anyone running IIS was never vulnerable except for all the times they were

      Here, FTFY.

      PS: Mister Ballmer, we know you've got plenty of time on your hands now, but be subtler, please.

    8. Re:Oh, man, what a mess by GodWasAnAlien · · Score: 2, Informative

      "secure commercial product"

      I assume you implying that closed source is more secure.

      Doe you really believe that? Why?
        - Do you think security by obscurity is real security?
        - Do you believe that closed source has more code audits?
        - Do you believe that there is less change of NSA or other back doors in closed source software.

      "IIS was never vulnerable..."

      Really? Try a search for "IIS SSL vulnerability".

    9. Re:Oh, man, what a mess by Anonymuous+Coward · · Score: 2

      I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge.

      On the contrary, it may have made things harder.

      Reading the private key relies on forcing malloc() to reuse some small block from the free block list with a lower address than the block containing the key, insteading of simply carving a new block out of free memory (with an address higher than the key).

      That may be easier to do on a busy server, because you don't have to send millions of queries just to fragment its memory; you may just assume that malloc is already reusing freed blocks, and exploit the algorithm it uses to do that (eg by manipulating the length of payload to let it allocate some unusual size block for which some gap just before the key is the perfect fit).

    10. Re:Oh, man, what a mess by mysidia · · Score: 2

      You are correct about there being other IIS security vulnerabilities. There have also been other OpenSSL, Apache, and Nginx remote code execution vulnerabilities.

      The Nginx RCE could also be used to compromise key storage.... could do even better than that, could load an eavesdropping trojan into memory.

      The past IIS vulns did not necessarily easily compromise key storage.

      The Heartbleed bug is MUCH easier to exploit than any RCE bug, even though the RCE bugs are more useful for an attacker, if a server is known to be vulnerable to one.

    11. Re:Oh, man, what a mess by bloodhawk · · Score: 2

      With the amount of Bot Net's out their costing peanuts to rent it would be pretty tough to protect from this in any meaningful manner without prior knowledge of the exploit.

  4. Don't keep vulnerable servers running! by Anonymous Coward · · Score: 2, Insightful

    Most sites don't have PFS enabled, and that means anyone who has recorded a site's traffic prior to the publication of the bug only needs a short time to get the key and can then decrypt all recorded sessions. The Heartbleed exploit doesn't just jeopardize the data that is currently flowing through OpenSSL while the attacker is reading server memory through malicious heartbeat requests. If you used a vulnerable server via a public Wifi hotspot in the past two years and someone else recorded your session, then your data is potentially readable. No certificate revocation can fix that. The longer vulnerable servers have been kept online after the disclosure, the more attackers had a chance to get private server keys. These private keys compromise recorded traffic and they enable attackers to pose as the server in the future, because certificate revocation is utterly broken. Keeping vulnerable servers running for any amount of time was reckless.

    IMHO browsers should treat all existing certificates as untrusted. All certificate authorities should renew their root CA certificates and have old certificates removed from client software. The system is broken, but without making sure that all potentially compromised certificates are made unusable, many server admins will just keep using old certificates, and then there's no reason to trust SSL at all.

    And enable PFS, FFS!

    1. Re:Don't keep vulnerable servers running! by ledow · · Score: 2

      When I looked into my server, I found out:

      The OpenSSL library I'm using wasn't vulnerable.
      Thus, my keys are as "safe" as they were before.

      Also, to enable PFS, I would have to upgrade - to one of those OpenSSL versions that is vulnerable (but obviously there are "fixed" ones now).

      I would also only be able to use EC cryptography with PFS with OpenSSL. I don't trust EC personally, yet. It's just not been around long enough for me. And I find it suspicious that every time something happens, the answer is "Let's go to EC!". If anything, I suspect it might well be something that people we don't want deciding algorithms are driving us towards.

      Sorry, but until I trust EC, I can't trust PFS. And I can't use either until I upgrade to a version of OpenSSL that was vulnerable to this attack for a long time without anyone noticing (whereas my current version wasn't).

      Ironically I "score" more on certain SSL test sites with old OpenSSL than with the newer one... and I get artificially capped because I don't support EC.

      Until someone shows me that PKE is broken, then EC is not necessary for my usage. PFS is something I'd like but, as OpenSSL only supported it when using EC algorithms last I looked, I don't see it as any more secure.

  5. There are people that tust SSL-certificates??? by gweihir · · Score: 2

    Seriously, how out-of-touch can you get? That the X.509 global certificate system has been fundamentally compromised has been well-known for quire a few years to everybody that follows the news at least in a cursory fashion.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:There are people that tust SSL-certificates??? by fuzzyfuzzyfungus · · Score: 3, Informative

      The bigger issue is that even people who don't trust the (braindead; but too convenient to die) "Hey! Let's just trust about 150 zillion different 'secure' Certificate Authorities and if they signed the cert and it matches the domain everything must be OK!" are still pretty screwed if whatever specific certificate or certificates they are using are now also in the hands of some unknown and probably malicious 3rd party...

      There's a pretty big difference between 'because the system is pretty stupid, you can generate a valid certificate for any domain by knocking over any one of an alarming number of shoddy and/or institutionally captured CAs' and 'your private key, yours specifically, can be remotely slurped out of your system and used to impersonate it exactly'.

    2. Re:There are people that tust SSL-certificates??? by gweihir · · Score: 3, Insightful

      I am not sure it is a bigger issue, since many of these sites will not be publicly reachable. But it definitely is an issue foe example for large corporations that use SSL in their Intranet with self-signed certificates. They now have to wonder whether some of their staff has attacked their servers this way.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  6. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 2, Informative

    Be glad...

    I can see t with my browser, and this is, what I can read (among other things)
    :
    "Can you see this site? You shouldn't be able to, we have revoked the certificate. If you can still see this message, Certificate Revocation may be broken in your browser. See this post for more details."

  7. Re:I can't use cloudflare, connection is insecure by dghughes82 · · Score: 2

    Cloudflare said on their wall on Facebook that they were going to leave the site up, as a means of checking how browsers deal with revoked certs: https://www.facebook.com/Cloud... So Firefox is probably doing the right thing here. Last time I looked, Chrome didn't display any warning. Which is nice.

  8. Re:I can't use cloudflare, connection is insecure by _Shad0w_ · · Score: 4, Informative

    Chrome turns the "check for revocation" option off by default, it seems.

    --

    Yeah, I had a sig once; I got bored of it.

  9. And the cry goes up from ten thousand admins, by SuricouRaven · · Score: 4, Funny

    Fuck.

    (Except here in the UK, we are more creative with our profanity.)

    1. Re:And the cry goes up from ten thousand admins, by John+Bokma · · Score: 3, Funny

      By Jove!

      --

      Perl Programmer for hire
    2. Re:And the cry goes up from ten thousand admins, by Virtucon · · Score: 3, Funny

      Bollocks!

      --
      Harrison's Postulate - "For every action there is an equal and opposite criticism"
    3. Re:And the cry goes up from ten thousand admins, by Teun · · Score: 4, Funny

      I say!

      --
      "The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
    4. Re:And the cry goes up from ten thousand admins, by Nimey · · Score: 2

      Perkele!

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
  10. Obvious hack is obvious? by bjoswald · · Score: 2

    Well yeah, considering the severity and size of attack vector. I'm sure the NSA are having a field day over at HQ, too (Hi, BTW).

  11. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 2, Informative

    Chrome has online revocation check turned off by default - you can go to Settings -> Advanced and switch on "Check for server certificate revocation" under HTTPS/SSL section

  12. Re:The CA should not revoke the certificates, by mysidia · · Score: 5, Insightful

    the user of the keys should do this. Would you want to pay for new certs even if you were not affected by heartbleed?

    It's within the CA's right, however, to scan the URLS certified by each certificate, test for Heartbleed vulnerability --- and automatically revoke, if they determine that the site is vulnerable.

  13. Re:I can't use cloudflare, connection is insecure by lgw · · Score: 5, Funny

    Internet Explorer for the win (my head asploded):

    There is a problem with this websiteâ(TM)s security certificate.

    This organization's certificate has been revoked.

    Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

    We recommend that you close this webpage and do not continue to this website.

    Click here to close this webpage.

    I feel like I've fallen into Bizarro world, where IE is the safe browser and IIS the safe server. Maybe I should grow a goatee?

    --
    Socialism: a lie told by totalitarians and believed by fools.
  14. Re:I can't use cloudflare, connection is insecure by 93+Escort+Wagon · · Score: 2

    On iOS I get no such warning...

    And actually, the default OS X settings don't check revocation lists either. To enable that you need to open up "Keychain Access", go to "Preferences -> Certificates", and set both OCSP and CRL to "Best Attempt".

    --
    #DeleteChrome
  15. Tools for checking by bobstreo · · Score: 3, Informative

    There are a couple tools available at:

    https://github.com/Lekensteyn/...

    It's python based so YMMV

    They will tell you if you are vulnerable (See the README.md file)

  16. Re:The CA should not revoke the certificates, by mwvdlee · · Score: 5, Insightful

    Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  17. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 2, Insightful

    I'd guess "because online checking can be slow - as in literally _seconds_ before site starts loading!!11!" and "there's offline revocation list and Chrome updates often enough".

    Or may be "because NSAMI6KGB paid us to weaken the security".

  18. There is more where that came from by Anonymous Coward · · Score: 5, Interesting

    Coverity is a static analysis tool. It was tested on the source code with the Heartbleed vulnerability and did not find it. The developers of Coverity made a proof-of-concept modification to treat variables as tainted if they're subjected to endianess conversion, based on the assumption that such variables contain external and thus potentially hostile data. With this modification, Coverity finds the Heartbleed bug, as described in this blog post. Note the comment below the screenshot: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here." This may just be a consequence of not detecting all ways in which a tainted variable is sanitized, or it may point to more problems.

    1. Re:There is more where that came from by InsaneLampshade · · Score: 4, Interesting

      They thought malloc was too slow. http://www.tedunangst.com/flak...

  19. Re:The CA should not revoke the certificates, by Anonymous Coward · · Score: 5, Funny

    Pff now you're telling me the CA has the authority to tell me which certificates are bad??

    Oh piss on that!

  20. Re:The CA should not revoke the certificates, by beelsebob · · Score: 5, Insightful

    Yes... That's the entire point of a CA, to certify that a person really is that person. If the certificate is bad, they can no longer make that certification, so it really really really is their job to do that. It is in fact their only job.

  21. Re:The CA should not revoke the certificates, by dcollins117 · · Score: 4, Funny

    Pff now you're telling me the CA has the authority to tell me which certificates are bad??

    If that is an issue, there is nothing stopping you, or anyone, from becoming their own Certifcate Authority. I've done this for my own sites, since I am at least 97% sure I am who I claim to be.

  22. Firefox noticed for me by Chirs · · Score: 2

    Running Firefox 28 on Win7, it said the cert was revoked.

    1. Re:Firefox noticed for me by dbraden · · Score: 2

      Same here, but using Firefox 28 on OSX, error message "Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)".

  23. Re:The CA should not revoke the certificates, by mellon · · Score: 5, Informative

    It doesn't matter who revokes the keys. Right now only Firefox and Chrome ever check for revoked certs, and Chrome at least has this disabled by default. If you are running iOS or Android, your browser doesn't check the CRL before trusting the cert. So it's great if web sites revoke certs, but it doesn't actually change anything on the end user side, for the most part. I'm not saying anything about Windows platforms because I don't have access to any; it's possible that they do support CRLs. You can check whether your browser supports CRLs by going to this test URL. If you don't get a warning from your browser, your browser isn't checking CRLs.

  24. Re:The CA should not revoke the certificates, by mhotchin · · Score: 4, Informative

    IE 11 (at least) works properly, right out of the box:

    There is a problem with this website’s security certificate.

    This organization's certificate has been revoked.
    Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
    We recommend that you close this webpage and do not continue to this website.
    Click here to close this webpage.

  25. A simple question - Can you provide simple answer? by zacherynuk · · Score: 2

    How do I become a trusted root certificate authority ?

  26. Re:The CA should not revoke the certificates, by asjk · · Score: 2

    Safari 7.0.3 (9537.75.14) throws up a warning dialog and pauses the page load.

  27. Re:The CA should not revoke the certificates, by icebike · · Score: 2

    However, the CA should issue the new cert for free in this case. It costs a CA exactly nothing to issue a new cert. Its not a consumable commodity. Allowing them to indiscriminately cancel certs without proof of compromise gives them access to every site's checkbook.

    With no PROOF of being hacked, even the the fact that at some point in time the site was running a vulnerable openssl version seems insufficient proof to cancel a certificate, and require payment for a new one. Remember, none of this can be the fault of the site. As long as it is patched now.

    And before the CA cancels any certificate, they themselves better be assured that they were always running a clean stack.

    --
    Sig Battery depleted. Reverting to safe mode.
  28. Re:The CA should not revoke the certificates, by icebike · · Score: 2

    And you are in good company. Google, Apple, and Microsoft do the same.
    Chances are your users are just a certain of who you are as Google users are certain of who Google is.

    --
    Sig Battery depleted. Reverting to safe mode.
  29. Re:The CA should not revoke the certificates, by jopsen · · Score: 3

    Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.

    There is probably still a great deal of unpatched openSSL deployments out there.. and it'll probably be a while before they're all patched (if ever)...

  30. Re:The CA should not revoke the certificates, by wed128 · · Score: 3, Interesting

    OK, then they should invalidate ALL certificates, test customers for the patch, give patched customers new certs, and refuse to give new certs to unpatched customers. It's their business to maintain a 'web of trust'.

  31. Re:The CA should not revoke the certificates, by parkinglot777 · · Score: 3, Interesting

    There is probably still a great deal of unpatched openSSL deployments out there..

    I think you miss the GP point. I believe the GP is saying that the site could have been exploited for a while and the damage has already been done. The check just tell us that the site has been patched but NOT tell us how much the damage is done to users. As a result, some users do not know that their username/password have already been stolen by the exploitation (which is not caused by the user). I doubt that there is a gray area allowed in security. Once the security is breached, there is no guarantee to say that everything is now fine after the fixed/patched.

  32. Re:The CA should not revoke the certificates, by mysidia · · Score: 2

    Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.

    That's true, BUT for the ones that are patched now --- the admin probably understands the issue. The sites with negligent, clueless, or sloppy admins, will be unpatched sites mostly (or sites running earlier releases before the vulnerable version).