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.

Comments

I patched my tape library, that changed

[deongene]

one less vulnerable device

Re:I patched my tape library, that changed

[laffer1]

You can't just compare the number of vulnerabilities. You have to look at how critical they were. You have to look at what components they were in. For example, does Windows include IE? I'm sure your iOS and OS X numbers include Safari. For Linux, is this just the kernel, a distro or all distros?

Re:I patched my tape library, that changed

[PixetaledPikachu]

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Re:I patched my tape library, that changed

[Eunuchswear]

The other major change is that security sites are starting to actually TEST Linux

What does heartblead have to do with Linux? This bug was present on all platforms that had OpenSSL.

For example:

Microsoft Windows
MacOS
BSD Unix
Linux
VMS ....

We really should rethink web encryption.

[jellomizer]

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 should be easier to setup.

This difficulty is why organizations may not go that route. They can't risk taking there servers down for a day to get their site secure. If the choose the wrong cert company they either spend a ton of money, or risk getting a company not recognized by the web browser. Scaring off users.
Then you have security updates. Which may break what you have setup.

I personally think ssl should be enabled by default by the web server, then you send the cert company your key made during the install process. Then they will give you a data set that you add to your configuration to tell the browser to check against that cert location. Then the browser can decide the quality of the cert verifier.

Re:We really should rethink web encryption.

[Anonymous Coward]

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

Fail.

Re:We really should rethink web encryption.

[ledow]

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:We really should rethink web encryption.

[Anonymous Coward]

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

Re:We really should rethink web encryption.

[oodaloop]

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

Re:We really should rethink web encryption.

[Anonymous Coward]

Of course it's a sight. If no one sees your site, your very existence has no meaning.

Re:We really should rethink web encryption.

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

Re:We really should rethink web encryption.

[wonkey_monkey]

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.

Re:We really should rethink web encryption.

[Anonymous Coward]

But jellomizer's first language is English. He is just dumb.

Re:We really should rethink web encryption.

[Anonymous Coward]

You could always go with a managed service from companies like Rackspace to handle all of this for you.

Re:We really should rethink web encryption.

[Anonymous Coward]

IIS and Apache are servers, not browsers. Your post is invalid.

Re:We really should rethink web encryption.

[nine-times]

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 the same cert for Exchange, SMTP, IMAP, or other services, where do you go to do that? I couldn't tell you off the top of my head. The whole thing is pretty different from one version to another, so I'd probably have to poke around for 20 minutes just looking for the controls. Similarly, in Linux, I do it infrequently enough to need the instructions in front of me. If you ask me to put an SSL cert on some random shared hosting account, I'll have to go dig through the documentation for that host. My experience has been that the whole process is not hard, but it's not extremely obvious either. You need to be a decent admin who does it regularly to breeze through it.

Now you might ask, what's wrong with that? Shouldn't we expect the people setting up web servers to be decent admins? And that'd be great if we could leave it at that. However, if you've ever dealt with IT professionals, you'll know that the majority of them are not very good at their jobs. Believe me, I've supervised a lot of them, and even the ones who think they're super-brilliant hot-shots are often pretty sub-par. Even the ones that are pretty good usually have their weaknesses, and we all make mistakes.

So honestly, I agree, it should be easier. The process in general reminds me of some pieces of software that I've installed, where after you run the installer, you're supposed to manually run some commands on the CLI, edit some configuration files, edit the registry, or other manual tasks. That feeling of "This isn't hard, but it seems like you haven't thought this all through. You should have streamlined this process a bit."

If you have need of SSL, then you can spend the annual renewal on a decent CA.

I think part of the idea here was that we should all be using SSL. Encrypting web traffic shouldn't be a fringe case of "something used by people with money and expertise". Somehow, we should work on making it the default behavior. It should be cheap (or free) and easy, and setting up a web server without it should provide a bunch of warnings. Hell, visiting a website without it should generate warnings. But if you want to get to that point, then you'll probably need to streamline the process of getting a certificate, as well as making it cheaper.

Re: We really should rethink web encryption.

[Anonymous Coward]

No yours is.

Re:We really should rethink web encryption.

[Anonymous Coward]

If you trust them to issue you a non-compromised certificate now, you should be able to trust them enough to protect your self-generated cert for a DNS-like verification and lookup system.

It's not an improvement, but it's really no worse than what we already have.

Re:We really should rethink web encryption.

[jeremyp]

Only if it is the private key.

Re:We really should rethink web encryption.

[Anubis IV]

If you trust them to issue you a non-compromised certificate now, you should be able to trust them enough to protect your self-generated cert for a DNS-like verification and lookup system.

It's not an improvement, but it's really no worse than what we already have.

The OP for this topic, with whom you seem to be siding, was suggesting providing the CA with his private keys, and there's a massive difference between asking someone to verify your identity on a one-time basis and trusting someone to protect your identity in perpetuity. Going off of some of what was said by you and the OP...

A) I don't need to "trust them to issue [me] a non-compromised certificate", because that's not how compromised certificates work. When a CA issues you a cert, the first thing you do is check over it for errors. If there are any, you don't publish it on your site. You get a new cert. That's it. Compromise averted.

B) The primary problem with the current system is that fraudulent certificates for your site/service can be issued by unscrupulous/compromised CAs to people other than yourself. They'll be able to pose as you until you get the cert revoked, potentially compromising a subset of your users, but your idea does nothing to address that issue since false self-generated certs could be held by CAs just as easily, so we'd continue dealing with it as we do now: revoking certs, delisting CAs (e.g. CNNIC), etc..

C) Another annoyance with the current system is that if the issuing CA gets compromised, you'll probably want to procure a new cert from a different CA. Annoying, but not catastrophic...unlike the OP's idea. More on that in a moment.

D) The worst thing that can happen in any system is that your private keys get compromised. Anyone (e.g. hacker, nation state with a court order, etc.) who gets their hands on your private keys can not only pose as you or eavesdrop on your current and future encrypted communication, but can also decrypt any past communication they may have managed to collect. The current system we use has a single point of failure: you. The OP's system introduces the CA as an additional point of failure, with the end result being that when the CA gets compromised, it goes from being the nuisance it is now to being an outright catastrophe.

E) Now multiply the catastrophe by tens of thousands, since when the CA got compromised, it wasn't just you that the bad guys gained access to: they also got the same level of access to everyone else who was issued a cert by that CA.

Re:We really should rethink web encryption.

[radarskiy]

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

Commercial libraries

[Anonymous Coward]

Fewer software makers are willing to embed open source software due to the high risk of including wide open security holes in their products. Aside from the reduced security risks, commercial libraries often come with legal indemnification clauses, which bring extra business value.

Re:Commercial libraries

[Zero__Kelvin]

"Fewer software makers are willing to embed open source software due to the high risk of including wide open security holes in their products."

Well that certainly explains the vast majority of commercial embedded systems run Linux, then, doesn't it?

"Aside from the reduced security risks, commercial libraries often come with legal indemnification clauses, which bring extra business value."

Are you trolling, or just a moron? Point me to one software product that doesn't leave the onus on the developer. Just one. I can't wait to see your link. Show me just one commercial proprietary product that says "use us and we'll protect you in court when your/our code gets hacked"

Re:Commercial libraries

[Anonymous Coward]

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.

Re:Commercial libraries

[Anonymous Coward]

People love cheap shit, until it breaks, then they look for someone to blame.

Re:Commercial libraries

[Anonymous Coward]

Are you trolling, or just a moron?

Hehheh, Linux-man got butthurt.

Re:Commercial libraries

[mwvdlee]

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.

Re:Commercial libraries

[RabidReindeer]

People love cheap shit, until it breaks, then they look for someone to blame.

People love cheap shit, until it breaks, then they look for someone other than themselves to blame.

FTFY

Re:Commercial libraries

[Chris Mattern]

Lame comebacks don't change the fact the OP's claim is not just blatantly false, it is ridiculously false.

empty platitudes, going forward

[Anonymous Coward]

change the security conversation

To demonstrate compliance with business practice, bring your A-game to the table and rephrase as a football analogy.

Obviously not

[Anonymous Coward]

Betteridge's law of headlines says no.

http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines

The Little Logo That Could

[TheRealHocusLocus]

Heartbleed was The Little Logo That Could. 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 to drop it onto a business card or T-shirt. Network news teasers and splashes beyond count. Just what is that supposed to mean anyway? A padlock on a bit-tornado? A Hamburgler robber mask on a credit card? A dagger spewing colorful Puff the Magic Dragon Bit Barf? Fingers on a keyboard (hacker fingers!!)?

Simplicity and scalability is power in logo design. A great logo must be simple enough to stencil, to reproduce. In your face elegant, coat and tails casual. Equally at home atop a skyscraper or fresh from a spray can in the 'Hood. Codenomicon really outdid themselves on this one, a touch of Art Deco and a ton of tasteful restraint. All lines are either gracefully curved or straight and vertical. It does not matter how you affix a Heartbleed logo, it will command the attention without silly tricks. Its topological genus of one is a master stroke of genius, and preserves its visual identity even if hastily drawn.

The Heartbleed logo is the first logo designed in almost 50 years that has no need for a drop shadow.
There can be no higher praise.

Re:The Little Logo That Could

[Trepidity]

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.

Re:The Little Logo That Could

[wonkey_monkey]

The Heartbleed logo is the first logo designed in almost 50 years that has no need for a drop shadow.

http://google.com/
http://www.bbc.co.uk/

Re:The Little Logo That Could

[Anonymous Coward]

Are drop shadows really that popular in logos?

No. Do a google search for the word "logo" and see for yourself.

Re:The Little Logo That Could

[Anonymous Coward]

no

Re:The Little Logo That Could

[Anonymous Coward]

God, I hate these flat UI changes... give me a damn drop shadow so I can easily tell a button from random space!

The buzz was needed

[zoefff]

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

Re:The buzz was needed

[Anonymous Coward]

> certificates renewed

So how many site certificates were (re)created using a secure random number generator?

MARKETING BULLSHIT

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

[Eunuchswear]

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.

Re:Heartblead could have been found earlier.

[Anonymous Coward]

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

IIRC the OpenSSL maintainers where chronically underpaid and had no motivation to secure it beyond specific (paid for) certifications. The maintainers of the libreSSL fork had a nice time flaming every bit of wrong, broken, misleading or just useless code they removed with detailed descriptions of just what sanity defying problems it had. They also flamed the certifications, leaving everyone depending on these stranded with OpenSSL.
 

Re:Heartblead could have been found earlier.

[Anonymous Coward]

There's a lot that could have prevented that bug, but the biggest thing that stands out to me was the sloppy code in the function itself.

https://github.com/openssl/ope...

Line 1450: First of all, exactly what "&s->s3->rrec.data[0]" is isn't anywhere near apparent enough. However, the big failing is that, even if we know that it's a buffer of untrusted network data, the first thing we're going to do is rename it to a single letter, thereby making it even less obvious where values referenced by the pointer are coming from.

Line 1452 & 1453: These variables should really be named "payload_size" and "padding_size" or something similar, to reflect that they aren't the payload and padding themselves, but rather, just the size of these things.

Line 1457: Several problems here:

First of all, "p" doesn't scream "OMG don't trust any data read from this pointer!" like it should. Thus, this line doesn't stand out as one that needs particular attention in code review.

Second, even if we're still aware that "p" points to untrusted data, we just stored that data into "payload" using a macro that conceals the fact that "payload" is an output rather than an input. Thus, we might be aware that we just looked at the data in that buffer, but still not be aware that "payload" is now untrusted data, as the macro looks like a function call, and functions can't modify values not passed by reference.

Third, since "payload" is named as if it contains the data rather than the size of the data, we may not even think it's a problem that it's never checked for validity since we know the payload of the heartbeat packet is irrelevant.

Line 1480: ...and now, enabled by the "payload" variable that we've made ourselves blissfully unaware of the contents of, we copy a bunch of random data into an outgoing packet buffer.

You want to prevent bugs like this? Here's some rules:

1. Name your variables such that any moron can figure out what the fuck is in them without having to search all over the code. Whomever is reviewing your code may not remember what the fuck "&s->s3->rrec.data[0]" is, and they may not remember what the "p" you declared just a few lines ago is. Make your variable names obvious enough and it'll be more obvious when you're misusing them.

2. Don't make macros that modify their parameters. I know, this is hard if the macro needs more than one statement, but fuck, do you want it to be obvious what your code does or not?

I think the biggest problem is that a lot of programmers are under the impression that, as long as code compiles and does what it is supposed to, then the code is fine and no one has any right to complain about it. However, I would have looked at that code for about ten seconds, realized it was too hard to follow, and told whomever sent it to me "no thanks, it's too hard to follow." If it isn't obvious what a piece of code does, or if it isn't obvious that it does it correctly, then it isn't obvious that the code is secure.

So is the code secure? Well, you may have people review each other's code for the added security that that brings, but if the code they're reviewing is difficult enough to follow that they aren't willing to take the time to understand it, then you might as well not even ask them to look it over.

I'm sure that's what happened here. Dude just typed out some code when he should have been sleeping, submitted it, and the next day someone looked at the code to review it, realized that following what was going on with all of those misnomer and non-descriptive variables was going to require some actual effort, and just said "fuck it, dude is cool, and he wouldn't have submitted it if it didn't work." After all, what was he going to do? Send it back with the message "uhm, yeah, I'm not taking the time to try to follow this code, why don't y

That's all well and good but...

[Anonymous Coward]

can they see my dick pics?

Codenomicon and Heartbleed ..

[DougPaulson]

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.

Best-practice ciphers

[emil]

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

To fix these flaws, apply these cipher best practices 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+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
SSLCompression Off
SSLHonorCipherOrder On

To summarize:

• - Apply vendor patches for your OpenSSL with some degree of haste.
• - Check the best practice cipher page at least once per quarter.

Heartbleed - how it could have been found

[dwheeler]

My article How to Prevent the next Heartbleed 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.