The bug itself is pretty technical so let’s break it down from the top:
However, HTTP is not secure at all because everything is just a bunch of text flying around. This of course won’t work for sensitive things like banking so a protocol called SSL was created that allows computers to encrypt data before sending it to each other. Combining the SSL protocol with HTTP gives us HTTPS, which you can see at the beginning of the URL when viewing a secure website
How SSL works
Encryption is done by using something called “keys” that come in pairs. These are special files that can only decrypt stuff that’s been encrypted by the other. There’s a public key which your computer gets and a private key that only the server has. This way only you and the server can read each other’s messages and it can’t be intercepted by anyone else. 
Remember SSL is just a protocol so there still has to be software that actually uses these rules and lets computers talk. The most popular software for this is called OpenSSL, an open-source project that’s used on lots of servers (and lots of devices like your internet router and mobile phone).
What is a heartbeat?
Connections over the internet take a tiny bit of processing power to set up when you use them so we try to avoid repeating that by keeping things “alive”. This means sending a tiny bit of data to let the other computer know that you’re still on the line and not to close the connection. In SSL, this feature is called the “heartbeat” (hence the name “heartbleed”).
When your computer sends a heartbeat to the server, it delivers a little bit of data (called the payload) and a number describing how big that data is (in bytes). The server then responds with the exact same thing by storing your message in memory, then copying it out and sending it back to you. It knows how much to copy and send back because your computer told it how big the message was.
Unfortunately, in certain versions of OpenSSL, the heartbeat feature had a bug in one single line of code which didn’t check if the size you claimed was actually the size of what you sent. This meant you could send a tiny bit of data (just 1 byte) and claim it was a lot bigger (up to 65536 bytes). Without this security check, the server just goes ahead and takes a big chunk of memory and sends it back to you, thinking that’s what you sent it originally.
You can probably see the problem here since you get back information that contains stuff that you didn’t send, and because this is easy to automate, an attacker can start to download lots of these chunks and get good look at what’s in the server’s memory.
It can be passwords the server is processing as people are logging in, it can be emails and billing info, or in the worst case scenario, it can be the copy of the server’s private encryption key. If someone gets their hands on this, they can start looking at any of the data being sent between the users and the server without them knowing. This is obviously really bad.
The fact that there’s no actual “hacking” involved here other than changing what you send to the server (which very easy to do) means that this attack is practically undetectable during the 2 years that this bug has existed. 
A lot of sites out there have OpenSSL running somewhere so it’s a big target for attacks but updates are happening rapidly. There haven’t been reports of any major breaches but again it’s hard to even know it happened. OpenSSL is also used in lots of other things like business software, smartphones and other devices so there’s that whole angle that hasn’t really been analyzed yet.
There’s not much the average user can do. Changing your passwords is recommended and should be done once the service you’re using has updated their software (all the major sites have by now). Also, anyone using Chrome should make sure that the “Check for server certificate revocation” option is checked in their browser settings. Any apps on your desktops, tablets and phones should be checked and kept up to date as well during the next few weeks.