Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday May 09 2014, @02:50PM   Printer-friendly
from the the-gift-that-keeps-on-giving dept.

Ars Technica reports that four weeks after its disclosure huge swaths of the Internet remain vulnerable to Heartbleed. The article suggests that over 300,000 servers remain vulnerable.

What steps have you taken to protect yourself from this bug? What browser addons have you installed? Have you checked/updated the firmware on your home router? If you work in IT, what has the reaction been? Has your site been compromised? Has vulnerable code been updated, new keys genned, new certificates obtained, and old ones revoked?

Since the OpenSSL library is now undergoing a security review and a fork of it is underway as LibreSSL, it is possible that other vulnerabilities will be discovered. Then what? How likely is it that we will need to repeat this cleanup effort?

(more after the break)

The Heartbleed bug "is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet." The bug affects not only computer servers, but also routers and even some Android phones, too. Even software like LibreOffice, WinSCP, and FileMaker have versions with the bug and need to be updated. The history, behavior, and impact of this bug are well-explained and summarized on Wikipedia. Therein is this recommendation:

Although patching software (the OpenSSL library and any statically linked binaries) fixes the bug, running software will continue to use its in-memory OpenSSL code with the bug until each application is shut down and restarted, so that the patched code can be loaded. Further, in order to regain privacy and secrecy, all private or secret data must be replaced, since it is not possible to know if they were compromised while the vulnerable code was in use:[68]

  • all possibly compromised private key-public key pairs must be regenerated,
  • all certificates linked to those possibly compromised key pairs need to be revoked and replaced, and
  • all passwords on the possibly compromised servers need to be changed.

SN's coverage of this vulnerability includes:

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by bill_mcgonigle on Saturday May 10 2014, @06:15AM

    by bill_mcgonigle (1105) on Saturday May 10 2014, @06:15AM (#41507)

    Ran updates, same as most bugs. One vendor-managed server doesn't have an update yet ("real soon, promise!") so the certificate there is the old one. The HTTPS connections to that machine all come from internal sources though, so external attacks aren't a huge risk (it does a different protocol to the world). All the others servers got a new certificate. Took the opportunity to upgrade to a real authority since 5-yr DV wildcard certs are just $150 now.

    The only real pain in the process is the wide disparity in TLS configuration in software. This daemon wants a separate file for cert, key, and chain, this one wants the cert and chain in one PEM, this other one wants them all in a PEM, this one wants the CA cert while this other one uses the mozilla certificate store, etc. I wound up making a symlink tree with each apps having a directory with its tls dependencies just to keep things sane.