Forgot your password?
Security Bug

Private Keys Stolen Within Hours From Heartbleed OpenSSL Site 151

Posted by samzenpus
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."
This discussion has been archived. No new comments can be posted.

Private Keys Stolen Within Hours From Heartbleed OpenSSL Site

Comments Filter:
  • by mlts (1038732) on Sunday April 13, 2014 @01:13PM (#46741187)

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

  • by Anonymous Coward on Sunday April 13, 2014 @01:20PM (#46741233)

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

  • by fuzzyfuzzyfungus (1223518) on Sunday April 13, 2014 @01:28PM (#46741303) Journal
    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'.
  • by _Shad0w_ (127912) on Sunday April 13, 2014 @01:32PM (#46741323)

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

  • by Anonymous Coward on Sunday April 13, 2014 @01:46PM (#46741397)

    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

  • by mysidia (191772) on Sunday April 13, 2014 @02:01PM (#46741495)

    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.

  • Tools for checking (Score:4, Informative)

    by bobstreo (1320787) on Sunday April 13, 2014 @02:08PM (#46741531)

    There are a couple tools available at: []

    It's python based so YMMV

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

  • by Anonymous Coward on Sunday April 13, 2014 @02:58PM (#46741895)

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

  • by Anonymous Coward on Sunday April 13, 2014 @03:22PM (#46742067)

    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.

  • by GodWasAnAlien (206300) on Sunday April 13, 2014 @03:41PM (#46742155)

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

  • by mellon (7048) on Sunday April 13, 2014 @05:16PM (#46742661) Homepage

    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.

  • by mhotchin (791085) <slashdot@hotchin. n e t> on Sunday April 13, 2014 @05:20PM (#46742695)

    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.

That does not compute.