Slashdot Mirror
Heartbleed One Year Later: Has Anything Changed?
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.
one less vulnerable device
then you send the cert company your key made during the install process
Fail.
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.
Aside from the reduced security risks, commercial libraries often come with legal indemnification clauses, which bring extra business value.
ROFLMAO You sir/madame are a fool by any other name. Legal indemnification clauses are in the commercial software and open source and free/libre software alike. They all say use at your own risk and you will not hold the developer / company / organisation liable for any losses or damages arising from use of said software. Otherwise Microsoft Corporation would have been bankrupt decades ago.
The Heartbleed logo is the first logo designed in almost 50 years that has no need for a drop shadow.
Are drop shadows really that popular in logos? The trend as I see it seems to be towards "flat" designs, both in logos and other areas like UIs (e.g. recent versions of iOS and OSX have dropped the pseudo-3d elements and specular highlights). When I think of a typical modern corporate logo I think of something like the new (2001) BP logo, which is entirely flat.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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 people are looking at security. Before Heartbleed, most people simply slapped SSL on top of whatever they used and called the connection encrypted. Now, I've had customers worried about MITM attacks through open WiFi hotspots, lack regular software updates, and other simple but obvious things that aren't as obvious to most people.
commercial libraries often come with legal indemnification clauses, which bring extra business value.
I know of NO software, whether it be libraries or applications, open source or closed source, that don't have a legal disclaimer in their license.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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).
Lame comebacks don't change the fact the OP's claim is not just blatantly false, it is ridiculously false.
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.
Watch this Heartland Institute video
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.