Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security

Heartbleed One Year Later: Has Anything Changed? 53

Posted by Soulskill from the vulnerability-names-have-gotten-a-lot-more-annoying dept.
darthcamaro writes: It was on April 7, 2014 that the CVE-2014-0160 vulnerability titled "TLS heartbeat read overrun" in OpenSSL was first publicly disclosed — but to many its a bug known simply as Heartbleed. A new report from certificate vendor Venafi claims that 76% of organizations are still at risk, though it's a statistic that is contested by other vendors as well as other statistics. Qualys' SSL Pulse claims that only 0.3 percent of sites are still at risk. Whatever the risk is today, the bottom line is that Heartbleed did change the security conversation — but did it change it for the better or the worse? A related article explores how Heartbleed could have been found earlier.
This discussion has been archived. No new comments can be posted.

Heartbleed One Year Later: Has Anything Changed? More

Heartbleed One Year Later: Has Anything Changed?

Comments Filter:

  • I am not a full time systems administrator, but I have setup ssl sights before. And if you don't do it all the time or at least one every 6 months. The process is cumbersome and difficult.
    We have the cert agency otherwise the popular web browsers we'll create alerts stating how much of a horable institution you are for not shilling out cash for a key.
    Then IIS vs Apache vs other browsers have different rules to setup and sometimes it just doest work when you follow the instructions.

    It is a process that sho

    • Re:We really should rethink web encryption. (Score:4, Insightful)

      by Anonymous Coward on Wednesday April 08, 2015 @05:01AM (#49427861)

      then you send the cert company your key made during the install process

      Fail.

      • In addtion to sending the CSR, and not the key, scan your SSL server with the SSL Labs Scanner [ssllabs.com] and you will see many flaws.

        To fix these flaws, apply these cipher best practices [hynek.me] to lock out bad ciphers (RC4, export-grade ciphers), and deny the entire SSLv3 protocol which now has critical design flaws.

        The key to the best-practice ciphers are these Apache directives (this configuration is also effective on the older 0.9.8 OpenSSL):

        SSLProtocol ALL -SSLv2 -SSLv3
        SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES25

      • Re: (Score:2)

        by jeremyp ( 130771 )

        Only if it is the private key.

    • Re:We really should rethink web encryption. (Score:5, Insightful)

      by ledow ( 319597 ) on Wednesday April 08, 2015 @05:25AM (#49427897) Homepage

      If SSL'ing a site is more than a 10 minute process for you (not including the time to return the cert from the CA after you've sent them the CSR), including anything more than a single restart of the web service (and that doesn't even need to be a full restart with Apache, etc.) then I worry about how you go about it.

      SSL sites with existing keys - upgrading the key, or changing the order of allowed cryptography, etc. - that's literally a one-line change (to point to new certificate file, or change the configuration line) and a restart. If the site is visibly down for more than a second or two, I'll be disappointed.

      And in terms of CA's, just use the proper ones. If you have need of SSL, then you can spend the annual renewal on a decent CA. It's part of the running costs of having a web presence. Hell, if you're worried, use two different root CAs and if one gets revoked for whatever reason, you can just switch the config to the other.

      It's not difficult.

      And, you know what? If you have SSL and need SSL then there's a reason it SHOULDN'T be a brainless operation. Because that's just one part of securing the data being transferred.

      I do network admin and I only do SSL once a year or even less when the certificates expire. I'm often at a different employer by the time certificate renewal comes up and have to familiarise myself with software I've never used before and never put SSL certs into before. It's not that difficult a process at all.

      And your "solution" is exactly what happens already. The reason you get SSL errors if you just enable SSL is because the default cert isn't signed or is only local but it's (usually) there. To get it signed you make a CSR, upload it to your CA, and they send you back a certificate that you plug into. And then the browser decides the quality of that cert and trust chain.

      Sorry, mate, but if this is too difficult for you, you shouldn't BE setting up SSL sites. It sounds like you're doing it just to shut user's browsers up when they whinge. That's the EASY part of the process of making sure you're securely handling whatever data they are sending your way.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        While upgrading a cert might be easy if you have direct access to the server, many shared hosting providers provide extremely bulky and cumbersome interfaces for managing SSL.

        I don't know how many times I've had to help customers using ancient shared hosting solutions to upgrade SSL certs, and having to plan at least 30 minutes of downtime for the service at hand simply because the CRON the host uses to reload the Apache config only runs every 30 minutes.

        To get back OT: Yes, Heartbleed has changed the way p

      • If SSL'ing a site is more than a 10 minute process for you... then I worry about how you go about it.

        I think his point was that, if you know what you're doing and you do these sorts of things regularly, yes, it's pretty simple and quick. However, if you're not used to the process because you're not doing it frequently, it becomes more cumbersome and frustrating. For example, on Windows, the process has changed a bit over the years-- not the process of issuing the key, of course, but exactly where do you go in Windows to go through the whole process? What does that process look like? If you want to use

      • "Sorry, mate, but if this is too difficult for you, you shouldn't BE setting up SSL sites."

        It is in our interest that everyone else have secure setups. We have no means of stopping people from setting up SSL so we might as well help them do it right.

    • Re: (Score:1)

      by Anonymous Coward

      Forgive me, but I'm not sure I trust someones opinion who works on ssl "sights".

      • FYI, not everyone who speaks English speaks it as a first language.

      • Re: (Score:2, Funny)

        by wonkey_monkey ( 2592601 )

        Forgive me, but I'm not sure I trust the opinion of someone who doesn't know how to use apostrophes and doesn't capitalise initialisms.

  • Heartbleed was The Little Logo That Could [wikipedia.org]. Like the peace sign of the 60s, the happy face of the 70s. It broke a decades-long trend of overzealous graphic design to portray security vulnerabilities.

    For years! Over-matted and often disingenuously constructed stock photo montages of so-called 'security', 'hacker' or 'cybercrime' objects on highly saturated over-stylized texture backgrounds. You know what I mean: the kind of schlock that looks great on the screen but it is a design train wreck if you attempt t

  • The buzz was needed (Score:4, Insightful)

    by zoefff ( 61970 ) on Wednesday April 08, 2015 @06:58AM (#49428137)

    I think the awareness it created by doing an incorrect disclosure and the frantic reactions that followed, made it possible that many sites were patched, that otherwise were not patched at all, and certificates renewed, that otherwise would stay the same due to laziness of the maintainers.

    The legitimate question is of course if that outweighs having the whole world open to this vulnerability for a short amount of time. (On the other hand, they were open anyway).

  • MARKETING BULLSHIT (Score:1)

    by Anonymous Coward

    Heartbleed was patched before microsoft tried to portray linux as an insecure os. The microsoft os is more insecure and more dangerous to the average person than linux ever will be. Microsoft should be in jail for this alone. How many other pieces of shit from the microsoft employment line do we have to put up with and yes if you work for microsoft you are a piece of shit. fuck you.

  • Heartblead could have been found earlier. (Score:3, Insightful)

    by Eunuchswear ( 210685 ) on Wednesday April 08, 2015 @08:55AM (#49428711) Journal

    Heartblead could have been found earlier if the person writing the code for the heartbeat option had read the RFC describing the heartbeat option.

    The RFC explicitly described the error case that resulted in the heartblead bug and said that the implementation SHOULD check for it.

    This all gets wierder when you realise that the person who wrote the code was the same person who wrote the RFC.

  • Google discovered the vulnerability on March 21 and communicated it to Codenomicon and the OpenSSL Project. Codenomicon disclosed it to the public before it was patched. On April 07 the OpenSSL Project released a patch.
  • My article How to Prevent the next Heartbleed [dwheeler.com] lists in detail different ways that Heartbleed could have been found ahead-of-time. The point isn't to find it now, it's to learn from Heartbleed so we prevent a recurrence. There are many ways to detect vulnerabilities like this ahead of time... we need to start using some of them.

Slashdot Top Deals

To stay youthful, stay useful.

Close