Slashdot Mirror


Private Keys Stolen Within Hours From Heartbleed OpenSSL Site

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

151 comments

  1. The CA should not revoke the certificates, by Anonymous Coward · · Score: 0

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

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

    2. 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?
    3. 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!

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

    5. Re:The CA should not revoke the certificates, by radarskiy · · Score: 1

      I choose to read the AC as making a joke.

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

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

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

    9. Re:The CA should not revoke the certificates, by Teun · · Score: 1

      Android's Dolphin ignores the certificate and Firefox recognises it.

      --
      "The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
    10. Re:The CA should not revoke the certificates, by cbhacking · · Score: 1

      So does IE10.

      Internet Options -> Advanced -> Security (scroll near bottom) -> "Check for publisher's certificate revocation" and "Check for server's certificate revocation" are both checked for me. I know at least one of those options dates back to IE6, in fact, although it may have been inactive by default back then. I don't know when those options were made default, but at a guess I'd say IE8 or IE9.

      As a side note, if you are running Vista or later but *not* on IE11, you have TLS 1.1 and 1.2 disabled by default. They're easy to turn on (same place as above, just scroll a bit lower).

      --
      There's no place I could be, since I've found Serenity...
    11. Re:The CA should not revoke the certificates, by bloodhawk · · Score: 1

      Windows and IE's default behaviour is surprisingly the best of all the browser experiencing when it comes to revocation checking (not just the latest browser either, this behaviour dates back at least to 8).

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

    13. 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.
    14. 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.
    15. 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)...

    16. Re:The CA should not revoke the certificates, by Anonymous Coward · · Score: 0

      Safari 7.0.3 pops up a warning that the certificate has been revoked. The user can click through, though. I know lots of users are conditioned to completely ignore popup warnings.

      "It put up an error message."
      "What does the message say?"
      "I don't know, I clicked on OK."

    17. Re:The CA should not revoke the certificates, by Anonymous Coward · · Score: 0

      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.

      Trying to exploit other people's computers without permission is illegal in many countries.

      The heartbleed vulnerability only affects some using OpenSSL. For example, there are webservers that don't use OpenSSL, and you can use mod_nss with apache.

      Using OpenSSL and a vulnerable configuration is a choice, so companies are more liable than users in event "stuff happens" (thus I'm not changing my passwords till companies change their certs and update stuff).

    18. Re:The CA should not revoke the certificates, by Anonymous Coward · · Score: 0

      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.

      You say that as if FIrefox doesn't exist on Android. Firefox on Android shows an error message, and doesn't allow the user to proceed to the site.

      Of course, Chrome is available on Android, but it lets you visit the site.

      Just one of the reasons I have always used Firefox as my only browser on Android.

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

    20. Re:The CA should not revoke the certificates, by Anonymous Coward · · Score: 0

      Users ask the CA to revoke their keys, CA wants money for it, users don't want to pay because the simple fact that the key isn't secure anymore is reason enough to revoke it according to the CA. Who's at fault now?

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

    22. Re:The CA should not revoke the certificates, by Anonymous Coward · · Score: 0

      Opera won't even let you view the site at all. If you go somewhere where the cert is revoked, you get a warning message and one button, labeled "back to safety," which takes you to about:blank

      The server's security certificate is revoked!

      You attempted to reach revoked.grc.com, but the certificate that the server presented has been revoked by its issuer. This means that the security credentials the server presented absolutely should not be trusted. You may be communicating with an attacker.

      Back to safety

      Help me understand

      When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party that your computer trusts. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website you intended, and not a third party (such as an attacker on your network).

      In this case, the certificate presented to your browser has been revoked by its issuer. This usually means that the integrity of this certificate has been compromised, and that the certificate should not be trusted.

    23. Re:The CA should not revoke the certificates, by mysidia · · Score: 1

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

      If they're patched now but were vulnerable 1 month ago; there is a pretty good chance >90% that the keys have not been stolen.

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

    25. Re:The CA should not revoke the certificates, by jopsen · · Score: 1

      True, my point was that if you wanted to revoke (or just require rekeying) of certificates for hosts that was exploited... You would get a lot of exposed hosts by just dealing with those are still exposed :)

      I think there is enough low hanging fruit that dealing with people who did patch and rekey their certificates immediately is overkill... Or at least less critical than dealing with those still exposed.

  2. 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: 1

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

      Since this is in violation of the CA/Browser forum rules and Mozilla policies that pertain to trusted CA certificates; they are either lying, grossly negligent, OR both: if they have a root CA's private key ever loaded into an externally connected machine.

      In fact.... a CA root certificate itself, is not a trusted certificate for ANY domain name. They'd have to go out of their way to compromise it --- such as by issuing a OCSP responder certificate with the same keypair.

    4. Re:Even root CA certificates may be at risk. by Jane+Q.+Public · · Score: 0

      Also keep in mind that this involves a long, very serious, well-engineered attack.

      The developer who first won the challenge made literally millions of requests to the server, in order to gather and piece together the chunks of memory slurped up.

    5. Re:Even root CA certificates may be at risk. by Charliemopps · · Score: 1

      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. There was a time when I'd be surprised by insanely stupid security vulnerabilities but after a few years in the trade I've learned never to be surprised by anything.

    6. Re:Even root CA certificates may be at risk. by zacherynuk · · Score: 1

      YES! That's the whole point of this isn't it?

      To get everyone to get new certificates so that NSA and GCHQ (etc) has an easy and seamless MITM



      Back of the net.

      (sadface)

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

    8. Re:Even root CA certificates may be at risk. by cryptizard · · Score: 1

      How would getting new certificates let them do anything they couldn't do now?

    9. Re:Even root CA certificates may be at risk. by zacherynuk · · Score: 1

      My thinking was that perhaps they didn't have all the keys they required for current certificates, but now after a bit more... persuasion / data collection they have and so having people renew their certs would mean they have renewed access... Easier to dish out known keys than try and retrieve unknown keys.

    10. Re:Even root CA certificates may be at risk. by zacherynuk · · Score: 1

      ^ ffs I should think before I post sometimes. Sorry. Move along.

    11. Re:Even root CA certificates may be at risk. by TubeSteak · · Score: 1

      The CA has to be validated by third party auditors, before it can even be trusted.

      All those big box stores that got their credit card numbers hacked....
      Validated by third party auditors.

      IIRC, one of the stores was actively being exploited throughout the audit process and still passed.

      --
      [Fuck Beta]
      o0t!
  3. 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: 0, Troll

      Wow, "Insightful", seriously? /. mods really love them some unsubstantiated expert analysis from Anonymous Coward.

      Reality check: only 17.5% of SSL sites had heartbeat extension turned on. Most sensitive and popular sites have reissued and revoked certificates.

      Implementing Mr. WolfWings's solution would mean punishing 85% of the network because admin of myshittyblog.net has not yet fixed his shit and could have left his users vulnerable to NSA snooping.

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

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

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

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

    7. Re:https is dead by sjames · · Score: 1

      It'll never happen. Look at how hard it was to finally kill IE6. Then add all those embedded web servers in APs, switches, routers, NAS, etc etc and imagine getting their firmware updated (not to mention the devices that are no longer updated by the manufacturer).

    8. Re:https is dead by AHuxley · · Score: 1

      Hi jon,
      How safe are Perfect Forward Security (PFS) and other "per-session" encryption keys from this mess? Thanks

      --
      Domestic spying is now "Benign Information Gathering"
    9. Re:https is dead by Anonymous Coward · · Score: 0

      No it aint - it's called distrust and verify

      I don't have a single Root Certificate trusted in Firefox and only add exceptions for those places that I absolutely have to. Does it help? Don't know but seeing as how I've seen compromises such as the Diginotar and not been affected, I have to say that although it can be annoying, it's not as bad for me as anyone who trusts the entire chain.

    10. Re:https is dead by cbhacking · · Score: 1

      If the server (or client, for that matter) was hit with Heartbleed *during* (or shortly after) the session, the symmetric encryption key may have been retrieved and an attacker who had recorded the whole session could then decrypt it. If the session was ongoing and they were in position to do so, they could MitM it.

      Similarly, if the attacker used Heartbleed during the key exchange, they might have leaked the private information (from either endpoint) needed to derive the symmetric key, even if for some reason they didn't get they key directly. Same impact as above.

      If the attacker had used Heartbleed to steal the authentication private key prior to your session, they could have hit you with a MitM attack (appearing to be the authentic server) and you wouldn't have known.

      If the attacker recorded your session but did not MitM it *or* use Heartbleed on the server while the symmetric key was in memory, you're safe (even if they stole the private key beforehand, much less afterward). That's the beauty of PFS.

      --
      There's no place I could be, since I've found Serenity...
    11. Re:https is dead by Anonymous Coward · · Score: 1

      Look at how hard it was to finally kill IE6.

      Oh, how I wish it were so, but I think you should have said "Look at how hard it will be to finally kill IE6."

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

    13. Re:https is dead by zippthorne · · Score: 1

      Just like Apple stopped using certs signed by the compromised Comodo Root certificate to sign patches?

      Oh wait.. they they kept using it for years. They might still be using it, even.

      Certs are window dressing. Companies only care enough about them to make sure they don't throw warnings. If they can get away with it, they will invariably "solve" the issue by telling the users to reduce security settings.

      --
      Can you be Even More Awesome?!
    14. 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
    15. Re:https is dead by LordLimecat · · Score: 1

      CAs dont control whether a cert can still be used. The client configuration does that.

    16. Re:https is dead by LordLimecat · · Score: 1

      How do you know its your bank's public key and not someone elses?

      Thats the ENTIRE problem that CAs attempt to solve.

  4. 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 Anonymous Coward · · Score: 0

      Who wants to be the vulnerability was planted by the NSA, so after its discovery they could over a period of a couple days collect all the new certs being generated with a single warrant.

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

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

    7. Re:Oh, man, what a mess by Anonymous Coward · · Score: 0, Funny

      I believe the key point you made there is that anyone running IIS was never vulnerable. In a way, I consider this poetic justice for all those people who were too cheap to invest in a secure commercial product and tried to pinch pennies on OpenSSL. Karma's a bitch.

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

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

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

    12. Re:Oh, man, what a mess by Anonymous Coward · · Score: 0

      So we can ssafely assume that about 2 years ago, the (3-L-A and any other agencies) had their couple of hours cooking time and it was all downhill from there... privacy, schmivacy.

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

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

    15. Re:Oh, man, what a mess by Anonymous Coward · · Score: 0

      Mine was one of the above CentOS 6.0 installs. Love ya 1.0.0! Deciding to be lazy and not upgrade 6.5 was the best thing I ever did!

    16. Re:Oh, man, what a mess by c4t3l · · Score: 1

      2.5 million requests over the course of a day is a drop in the bucket for a large scale enterprise site. Sure, you would expect to see reasonable protections in place, but without some sort of prior knowledge (or dumb luck) it would be extremely difficult to find this bug (hence the two year window)... ----- Angels and ministers of grace defend us! -- Willie S.

    17. Re:Oh, man, what a mess by LordLimecat · · Score: 1

      I think the technical term for his post is "troll". That is, you've been trolled.

    18. Re:Oh, man, what a mess by pnutjam · · Score: 1

      I don't see what the point of that article is? Sure, lots of people were requesting certs. I saw their site slow to a crawl, from 30 seconds to 5 or 10 minutes to get the page to load so I could request certs.

      They did not however, change any of their intermediate trust chain certs. I don't see Commodo really did anything except issue certs as requested, like always.

  5. I can't use cloudflare, connection is insecure by Mirar · · Score: 1

    Interestingly enough, my browser (firefox) doesn't let me access https://www.cloudflarechallenge.com/, complaining about the security certificate...?

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

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

      That's good. They have since revoked the certificate which is used on that server, so the complaint is a sign that certificate revocation works in your browser, for that particular CA.

    3. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 0

      This is deliberate on their part.

      They have now revoked the certificate, and if you access the site, it tells you that you shouldn't be able to.

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

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

    6. Re:I can't use cloudflare, connection is insecure by michelcolman · · Score: 1

      In Safari on my Mac, I got a warning saying the security certificate could not be verified, and I could choose to simply continue. So then I got the text saying I shouldn't be able to see that site. Shouldn't the browser have actually said the security certificate had been revoked?

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

    8. 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.
    9. 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
    10. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 1

      Chrome has online revocation check turned off by default? Why? That does not make any sense at all! I would much rather have a false positive than a fail-open.

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

    12. Re:I can't use cloudflare, connection is insecure by K.+S.+Kyosuke · · Score: 1

      Ditto. IE works; Firefox, Chrome didn't even notice. ;/

      --
      Ezekiel 23:20
    13. Re:I can't use cloudflare, connection is insecure by Jonas+the+Bold · · Score: 1

      You're right! But why!?!?

      Why would it turn off checking revocation by default! Is there any possible reason that this is anything but grossly irresponsible?

      --
      Everything seemed to be going so nice
      'till the end of all beings punched right through the ice
    14. Re:I can't use cloudflare, connection is insecure by Kaenneth · · Score: 1

      In case no one noticed, MS view on security has changed a LOT since Windows 95 and IE 6.

    15. Re:I can't use cloudflare, connection is insecure by DarwinSurvivor · · Score: 1

      Not sure about the branded Chrome, but Chromium on my arch machine shows one hell of a scary message about the browser down-right refusing to connect to it due to the certificate.

    16. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 1
    17. Re:I can't use cloudflare, connection is insecure by _Shad0w_ · · Score: 1

      I think my preference would be to always attempt the check and in the case of a soft-fail to indicate that there was a soft-fail so the user can still make an informed decision. Or at least a semi-informed one.

      --

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

    18. Re:I can't use cloudflare, connection is insecure by Anonymous Coward · · Score: 0

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

      Maybe it’s different for Mavericks, but for Snow Leopard, I have done none of what you say, and when I use Safari to go to https://www.cloudflarechallenge.com, I get “The certificate for this website is invalid. ...” with the choices of "Show Certificate”, “Cancel”, or “Continue”. Clicking Show Certificate results in “This certificate has been revoked” in red.

    19. Re:I can't use cloudflare, connection is insecure by 93+Escort+Wagon · · Score: 1

      Hmm... I have a fully updated 10.6.8 (Snow Leopard) box that's been my media server for a number of years - it doesn't get used for anything else, even web browsing (it's an old MacBook Pro with a non-functional screen). Just now I connected to it using screen sharing, opened up Safari and went to the CloudFlare Challenge website. It loaded just fine, with no warnings whatsoever.

      I put Firefox on it and went to the same URL - Firefox tells me the certificate has been revoked.

      --
      #DeleteChrome
    20. Re:I can't use cloudflare, connection is insecure by zippthorne · · Score: 1

      Not sure about iOS, but the last time I set CRL on OS X to "require" I couldn't install patches.

      --
      Can you be Even More Awesome?!
    21. Re:I can't use cloudflare, connection is insecure by LordLimecat · · Score: 1

      Because it can massively slow down access to SSL sites.

  6. The internet is closed for renovations? by Anonymous Coward · · Score: 1

    Until they revoke all potentially compromised CA's and roll out a brand new set I don't see how they can consider the breach closed even if the vuln itself is fixed.

    1. Re:The internet is closed for renovations? by Joce640k · · Score: 1

      Luckily the system is designed to be able to do that.

      (And many sites have already done so).

      --
      No sig today...
    2. Re:The internet is closed for renovations? by Anonymous Coward · · Score: 0

      How many HTTPS enabled sites you visit every day? How many of those are not called "Google", "Facebook", "Twitter" (and others from top 10 in traffic rank)?

      For purposes of an average web surfer, breach _is_ closed. No need to shout "Sky is falling!" If you want to go offline for awhile to stay safe - good for you, pretty healthy and all.

      If anything, the problem lies in the past - we don't know and we can't know what could have been siphoned and by whom.

    3. Re:The internet is closed for renovations? by Anonymous Coward · · Score: 0

      " the problem lies in the past - we don't know and we can't know what could have been siphoned and by whom. " It was my point essentially. If the root certs are taken and that's not known at this time due to the nature of this exploit, org's would potentially NOT change them thinking they were secure, but are in fact compromised.

    4. Re:The internet is closed for renovations? by Anonymous Coward · · Score: 0

      Why would root certs be anywhere _near_ an Internet-facing computer? I'm not even talking "used in a SSL server on Internet-facing computer" (where it could be retrieved by this exploit) or even "be anywhere in the memory of an Internet-facing computer" (where there would be a chance to extract them by some other exploit).

  7. Time to reboot! by Anonymous Coward · · Score: 0

    Time to reboot the internets!

    Oh, and BTW, slightly off topic, but can I have a checkbox on my tax return so I can select where I want my tax money to go?
    Thank you.

  8. Nothing is proved or verified in this story and co by Anonymous Coward · · Score: 0

    Like the comment title said.

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

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

      https://www.openssl.org/docs/a... suggests that OpenSSL (the official upstream version at least) does in fact support DHE and PFS without EC.

    3. Re:Don't keep vulnerable servers running! by mysidia · · Score: 1

      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.

      The promise of PFS is that a private key compromised or lost after the fact does not compromise the contents of all sessions. Which means it's useless for an attacker to intercept thousands of SSH sessions, and then later make an attempt to break into the server --- they need private key at the time of any attack.

      You're argument is the equivalent of saying "I would use SSH, but I just don't trust PAM yet for my password authentication, which SSH seems to require. So I'll keep on using Telnet."

      By the way, ECDSA has been around over 10 years. In computer industry terms, that is quite ancient.

  10. 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.
    3. Re:There are people that tust SSL-certificates??? by fuzzyfuzzyfungus · · Score: 1

      I agree that it isn't a bigger issue in terms of expected ongoing pain/users affected, since the issue with trusting too many shady/incompetent CAs is showing no signs of real solution ('pinning' is an OK hack, so far as it goes; but it doesn't go very far on most users' systems and nobody seems to have an actual ready-for-prime-time solution that shows signs of making it out the door).

      I was thinking 'bigger' in that only SSLed stuff accessed by excessively-trusting systems can be compromised by a rogue or incompetent CA, while anything can be compromised (and relatively silently, some atypically clueful person tends to notice the shady certs eventually, which is much less likely with a perfect copy of the actual private keys) if you have the same private key material as the legitimate host.

      So, barring the possibility of some particularly nasty targeted exploit against some specific organizations, affected population is likely to be smaller; but the set of vulnerable systems is necessarily larger. I really didn't make what I meant by 'bigger' clear originally, did I...

  11. Oh please... by Anonymous Coward · · Score: 1

    Like this would come as a surprise?
    Like heartbleed in itself is a surprise? For every major zero day like this out from the dark there is ten more in the forest.
    General people just have no clue. Most organizations have no clue. Media have no clue. Just people in the dark know.
    Anyone working in the industry would know better than to trust anything online or supposedly safe.
    Secret stuff fares far better offline or in general "snail-mail", than online.
    No software is safe, ever has been or ever will be.
    The chain of trust for your program scope (hw, em-radiation, firmware, os etc) is just too big to consider safe at large.

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

    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 Anonymous Coward · · Score: 1

      Bloody hell.

    4. 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."
    5. Re:And the cry goes up from ten thousand admins, by Nimey · · Score: 2

      Perkele!

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
    6. Re:And the cry goes up from ten thousand admins, by Anonymous Coward · · Score: 0

      Poppycock!

    7. Re:And the cry goes up from ten thousand admins, by MrNemesis · · Score: 1

      As an atypically profane Brit, there's much to love even about the simple* word "fuck".

      "You know, Minister, I believe that in the long view of history, the British Empire will be remembered only for two things... The game of soccer. And the expression 'fuck off'."
      - The last Governor of South Yemen, in conversation with then-Defence Minister Denis Healey on the eve of South Yemen's independence.

      Personally, members of my team are fond of variations along the lines of "Fuck, the fucking fucker's fucked!" since one gets to use the word fuck as an exclamation, a verb, an article and an adjective; concise, immensely satisfying to say yet still grammatically correct.

      * Not a simple word at all really since, handled correctly, it can convey pretty much any meaning. It's frequently spotted as a metasyntactic variable in particularly hairy functions, wibblefuck being a common variation/combination. My favourite spot of this was "fuckwomble**" in some in-house LDAP code which entered company lexicon as an abbreviation for someone in compliance with Tucker's Law.

      ** A Womble is of course one of the inhabitants of Wimbledon Common who make a living by picking up rubbish. The coder in question had assigned variables named after all of the wombles, and after running out of names once he hit Bulgaria, started using a variety of swearwords rather than proceeding somewhat-logically through other countries of eastern europe. Given the nature of the code, it was a decision I could only applaud.

      --
      Moderation Total: -1 Troll, +3 Goat
    8. Re:And the cry goes up from ten thousand admins, by SuricouRaven · · Score: 1

      All good suggestions, but none of them quite how I'd imagined it:

      Bloody 'Ell! How'd he go and miss an unchecked length field? Now I'm in all weekend workin' me bollocks off updating every server 'cos some fuckin' wanker couldn't be arsed to get his security-critical code reviewed.

  13. The Little People by Anonymous Coward · · Score: 0

    The vast majority of the world won't know about certificates, won't know what OSSL is, and even if it was explained to them in the most funniest, interesting and captivating of methods they would switch off and still not be curious while they fill out their lottery forms and moan about the weather, taxes, government and many other things that they prioritize.

    They won't know or care no matter the effort to make them.

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

  15. I'm Smelling Something by Anonymous Coward · · Score: 0

    Until people start saying 'This is all lies, prove it! Right now! In front of me! Oh look it didn't happen and OpenSSL is fixed now anyway." they will believe all the spoon-feeding of crap that Microsoft and its allies are dishing out to turn XP owners away from Linux, Chromebook's, Mac's, etc and only buy Microsoft. This is going to go on for weeks and weeks with newer and more unbelievable stories. And the gullible will believe. Pity.

    I'm telling you, as long as you believe all of this hot air, this is what is going to happen. Disbelieve now, do yourselves a favor and cut the rot out before it can grow any more. Keep this stuff at arms length where it can do no unverifiable harm.

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

    1. Re:Tools for checking by cbhacking · · Score: 1

      The cool feature of Pacemaker is that it checks TLS *clients*, actually. There are other tools for server checks (one of which is included with Pacemaker) but it's actually very important to make sure any clients you have are invulnerable to Heartbleed as well. Software that ships with bundled or integrated OpenSSL libraries - and I've seen quite a few - could be vulnerable to this.

      --
      There's no place I could be, since I've found Serenity...
  17. NSA has the keys to the kingdom by Anonymous Coward · · Score: 0

    NSA has the keys to the kingdom

    They have access to the CA's
    They have access to RSA's keys.

    This was in the news years ago. Why the sudden panic now?

  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 TapeCutter · · Score: 1

      OpenSSL has is own memory manager that sits on top of malloc(), why I'm not sure?

      --
      And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
    2. Re:There is more where that came from by InsaneLampshade · · Score: 4, Interesting

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

    3. Re:There is more where that came from by Anonymous Coward · · Score: 1

      They thought malloc was too slow.

      http://www.tedunangst.com/flak...

      It usually isn't especially fast. Lots of software avoid using malloc where possible.

  19. 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)".

  20. Bully! by Anonymous Coward · · Score: 0

    Bully!

  21. Trolls by Anonymous Coward · · Score: 0

    samzenpus and Billly Gates this article is nothing more than a troll by a pair of assholes.

    And its assholes like these who caused me to change my /. password and throw it away 2 years ago.

    And slashdot's relation to think geek is why I stopped shopping there.

  22. 6 days by Anonymous Coward · · Score: 1

    The announcement and fix have been "out" for 6 days. Last Monday it hit the fan, and the world went crazy. I recovered some data from when two hard disk platters went from 32 bad blocks to 57 bad blocks to 269 bad blocks to 643 bad blocks in two days. Then I checked and I was running OpenSSL1.0.1e, and being vulnerable, grabbed 1.0.1f and updated about 10 more software packages. With all the md5 checksums, downloading extras that some of the newer packages needed, rebuilding my build scripts and testing....took another day. So mine has been fixed since Wednesday. Now its Sunday, and I'm still hearing about this. Its true that OpenSSL has over 433000 lines of source of which about 70% is C, and because its non-trivial, auditing it is hard. The guy who added the heartbeat extension also added it in RFC6520 for the Internet Engineering Task Force. He missed counting the incoming packet size and returning a packet of the same size. So did the guy (also with PhD in CS) who reviewed it. And the yelping goes on. Why oh why after this many days, are people not downloading and fixing already? Its been 6 days. Yes the two made a mistake. Those that have not applied the fix by late Tuesday, have made an even bigger one.

  23. Slashdot is slow by Anonymous Coward · · Score: 0

    What the heck, Slashdot? I read about this yesterday somewhere else. Has Slashdot become irrelevant? /don't answer that

  24. stolen? by Anonymous Coward · · Score: 0

    "private-keys-stolen-within-hours-from-heartbleed-openssl-site"

    "Stolen" is a word that has a meaning.
    If someone says look here and try to get my keys, "stolen" is the wrong word.

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

    How do I become a trusted root certificate authority ?

  26. Re:A simple question - Can you provide simple answ by Anonymous Coward · · Score: 0

    You wave a large amount of money under the noses of browser vendors to get your root certificate added.

    Preferably you should also look like you know what you are doing and probably have some ISO numbers after your company name.

  27. What if by koan · · Score: 1

    What if the NSA has hacked sites like sourceforge, github, or whatever, what if they were able to compromise code on all these sites by gaining root level access or through another method.

    What if nothing can be trusted?

    --
    "If any question why we died, Tell them because our fathers lied."
    1. Re:What if by Anonymous Coward · · Score: 0

      Git is specifically designed to be tamper evident. Anyone who already has a good local copy can verify that a remote repository is clean. Linus made that a requirement due to a break in that happened at kernel.org. IIRC that incident was one of the main reasons Linus wrote git in the first place.

  28. Re:A simple question - Can you provide simple answ by Anonymous Coward · · Score: 0

    most of them require a bit more than a large amount of money and/or ISO certification. They usually also require certain security measures are in place to protect the CA, like the Root CA being offline (i.e. not connected to the internet) and independent security evaluations done on their systems.

  29. Re:A simple question - Can you provide simple answ by dkf · · Score: 1

    How do I become a trusted root certificate authority ?

    You ask the browser vendors, who respond by asking some very pointed questions about how trusted you are. These sorts of questions include "do you have regular audits to ensure that you're managing your keys correctly?" and "what policies do you have in place for dealing with a security breach that compromises one of the keys you've signed?" Convince enough people that you're really trustworthy, and congratulations, you're a root CA. At least until the next time they ask those questions. It's only really recommended that you seek to become a root CA if you really like acting bureaucratically.

    You can also become a root CA for a particular browser by just installing a self-signed certificate in its list of trust roots. This is disappointingly common, and often a marker of an untrustworthy organisation, as the main reason for doing this is to enable SSL sniffing. Not recommended at all (and totally does not make your site trustworthy to anyone else, which is the usual point of having HTTPS set up). It does work better for specialist applications.

    Becoming a non-root CA is much easier. Just pay another CA enough money (or know the right people).

    --
    "Little does he know, but there is no 'I' in 'Idiot'!"
  30. There has to be a better way to secure comms by Methadras · · Score: 1

    This is getting outrageous. It really is. From storage of pin numbers to now root keys being at risk. This more or less is a confidence killer for internet based commerce regardless of the patches in place.

  31. Botman218 by Anonymous Coward · · Score: 0

    IE has had cert revocation checking turned on by default all the way back to IE7...