The other day I read an article about the fact that a large number of Heartbleed-affected websites regenerated their certificates with the same private key. This article was truly heartbreaking (pun intended!). I was amazed by the mobilisation of the internet to address this issue early on, but I've been equally shocked by the complete failure of efforts to fix it properly.
Quick Backgrounder (Skip if you know Heartbleed and understand key-pairs)
Heartbleed was a vulnerability in OpenSSL. It allowed attackers to get random blocks of memory from servers running OpenSSL. Given we use OpenSSL to establish encrypted communication channels between one place and another, the servers running this software have some very important secrets – namely the encryption keys for our communication: a big deal. Now, without going into a full explanation, the process we use for setting up this encryption uses a key-pair - one private key and a public key. These two keys are tied together and you cannot replace one without modifying the other. Then we use some fancy maths and pay some blood money to get an SSL Certificate which we then use to assert our identity when we establish a secure connection. OK, now lets talk about what happened …
Heartbleed has been a really amazing event from a few different angles, the breadth of the exposure, but also the speed and scope of the response. We have seen huge portions of the internet mobilised to react in a short amount of time which is largely unprecedented. Perhaps it is something in the air, or the slew of headline breaches we have seen over the last few months, but people heard about this issue and reacted. This is fantastic; it may have taken people a few hours or a few days, but they rushed to address the problem in a massive way. This was a success on the part of those publicising the issue and for those responsible for the vulnerable hosts out there on the internet.
Many of the people who responded did so in a way that demonstrated that we failed to properly educate what the actual issue was. The potential impact of the Heartbleed bug was that your private key used during the initial SSL/TLS handshake could be compromised. The advice that was given as far as remediating this issue was to replace your server's certificate. Many people did replace the certificate (fancy maths & blood money – see above) but used the same private key. This means they were just as exposed as before they made that effort. The failure here is in education. Those of us who understand this from a deep technical standpoint have the responsibility to explain the impact of major issues like this with explicit, clear, concise instructions to help those who are new to the game. We failed to do so as evidenced by these poor people who wasted their time replacing their certificates without generating a new private key.
To make sure I am eating my own dog food, here is the cheat sheet for what you need to do for OpenSSL
1. Generate a new private key (2048 bits 'cause why not?)
openssl genrsa -des3 -out privkey.pem 2048
2. Create a certificate signing request
openssl req -new -key privkey.pem -out cert.csr
We are making progress! We found an issue, we reacted, the world responded. We just need add a little education in that flow for the future. Our industry is fantastic at pointing out where things go wrong and where vulnerabilities exist, but one area that needs improvement is education and the sharing of that knowledge in an easily digestible way. We need to remember that some of the most vulnerable are smaller sized businesses and organisations and simply don't have the budget or the specialist resources to decrypt all of the answers. Security is everyone's problem and therefore it is our responsibility to arm everyone with the basic knowledge they need to combat threats like Heartbleed when they hit, especially given the catastrophic nature of this vulnerability. It certainly won't be the last big security flaw, so let's all resolve to keep these principles in mind; and ultimately, it will make our jobs a lot easier in the long run.
Contributed by Russ Spitler VP of Product Strategy for AlienVault.