Etymology & Definition
The name comes from a concept called a "heartbeat".
When computers call each other they tend to be quite curt and hang up the moment they've got the information they wanted. A heartbeat is a form of nagging where one computer sends meaningless data through and demands a response with the intention of keeping the line open. (CPUs are not known for their charm.)
Transport Layer Security/Secure Sockets Layer (TLS/SSL - TLS being the newer version essentially) is the little padlock that appears in the address bar of your browser when you are securely connected to a website.
Newer versions of SSL have a heartbeat feature perhaps intended for interactive websites such as chat services or games that are very "chatty", for whom making a fresh call every time they want to communicate would be prohibitively time consuming.
SSL's heartbeat says the server should return any heartbeat data the client sends as is. So if the client sends it "Are we there yet?", the server sends back "Are we there yet?". This is technique called an echo.
A specific implementation of SSL called OpenSSL (used by ~2/3rds of web servers) has a bug that allows the client to send through "Are" and receive "Are<random contents of server memory>" back. It does this by telling the server that it has actually sent 17 characters through but only sending 3. Since the server is expecting to echo something back that is 17 characters long, it fills in the remaining 14 from whatever piece of memory is next to the place where it put the incoming 3 characters.
This kind of security hole is very old, very well known, easy to fix and a little unbelievable in something like OpenSSL. I'll leave the conspiracy theories to others though.
What can a hacker do with Heartbleed?
I have to reiterate that I could be quite wrong about much of this.
They can theoretically get the private key of the server in question. The secrecy of this key is the foundation on which many many other kinds of intrusions are prevented. Once they have this they'll be able to use a wide range of techniques to do all sorts of stuff.
It is very likely that a Heartbleed request will be stored within 64KB (the maximum read size of a single Heartbleed request) of someone's session ID or login request. This does allow them to login as you and your password will be visible as plain text.
Repeating myself - what they can do by combining Heartbleed with other techniques likely goes far beyond what I've mentioned here.
The outcome is the same - servers need to change their locks (get new keys) and do a thorough sweep, if not reinstall, of their servers. This is arguably a very good thing and might be a bit of a disaster for government surveillance.
Firstly, if you have an existing session ("remember me") with a large site like Google, you're probably ok to keep using it.
This is because their throughput is so large that memory on the dedicated SSL server containing sessions is probably cycled so fast that is it less likely your session will be picked up in transit. If it is, it might be picked up by a script-kiddie or hacking enthusiast that has comparatively tame/lame intentions.
However, in no circumstances should you login using your password or change your password for at least a week for large, well maintained sites and probably a great deal longer for smaller sites.
This will definitely expose your password as, even if it is processed on another server, it is decrypted on the SSL server and will be available as plain text to Heartbleed attacks.
It is important to note that the act of using an existing session will expose it to Heartbleed attacks. I can't work without Google though so I kinda have to use my session - I won't be logging in for a while though.
Clicking the "logout" button is more important than ever right now as it will invalidate the session.
If you're thinking about what I'm saying here, you'll see that I'm contradicting myself. Surely if I logout then I'll be forced to login, exposing my password.
This underlines that there is currently no way to safely use the affected sites. The integration between sites on much of the internet potentially exposes much more than what is directly affected by Heartbleed as well.
Don't use your credit card online for some time (as long as you can bear).
Don't re-use passwords. One site, one password. Even if the password is insecure, at least a hacker can't automatically test it against every site on the internet and turn one hacked site into 10 in a fraction of a second.
Security guys will tell you things about key stores and having passwords you can't remember but what I've mentioned above is much more important.
My current system for creating passwords goes like this:
- start with one of my 3 base passwords picked based on how secure I think the site I'm using is (Banking > Google/Amazon > everything else).
- add to it a word that I will come up with again and again if I think about the site (for my everything else category where it doesn't involve money, this is generally just the site's name).
- change every odd character in the added word one letter forwards in the alphabet and one letter backwards for every even character. E.g. "Google" becomes "Hnpfmd".
That'll give you passwords that you can remember that are not entirely trivial to crack. Try to make the base passwords genuinely good - something that requires a bit of practice to memorise.
And always remember: no-one really cares that much about you specifically and they're unlikely to focus on hacking you meaning a modicum of security is usually enough. If someone does see you as a valuable target then passwords alone are never gonna cut it anyway.
I also have 2 very insecure passwords that my friends and co-workers know respectively so that I can give them access to home file shares and the like.
If you have shared passwords across many sites, the damage is done and the time to change is months hence. I'm fairly certain that changing your password right now is madness.
Since 2/3rds of the security certificates are going to need to be replaced, certification authorities are probably gleefully losing their shit right now.
Here's a list if you're wondering what you should invest in - most affected are those for whom certificates are a larger portion of their business.
Many of the smaller systems that can be more easily attacked will be employee portals into company intranet applications. If you can come up with a way of investing in companies that will use and benefit from corporate espionage...
The aftermath could be quite underwhelming or it could be staggering. Either way it's very interesting.