Q:

How to explain Heartbleed without technical terms?

Most of my friends who are not experienced in computers want to know what Heartbleed is and how it works. How would one explain Heartbleed to someone without a technical background?

A:

How about this one from XKCD?

The most "non-technical" explanation I found.

A:

The analogy of the bank and bank employee
You call the bank to request a new bank account, to make an appointment - whatever. Somehow you and the bank make sure that you are who you are, and the bank is actually the bank. This is the TLS process that secures the connection between you and the bank, and we assume this is handled properly. 
The roles in this play

The bank: a webserver
The bank employee: the OpenSSL service for that server 
You (the bank robber): a bot fetching all it can get from that server

Staying connected - the heartbeat
A bank employee answers your call. You request some information. The employee says to wait a minute and disables his microphone. He can hear you, you cannot hear him. Then it's quiet. For a long time. You start to wonder if he hung up. So you say "hello?" The employee is instructed to echo whatever you say, and replies with "hello". This is the heartbeat to check if there is still a connection. 
Now with this peculiar bank employee, you need to say first how many words you are going to use before you ask if the employee is still online. So instead of saying "hello", you need to say "one: hello", or "two: hello there". The employee now knows he can reply with repeating those (first) two words, and then can continue to work on your request. This is the heartbeat protocol. 
The problem - the heartbleed - no check on what is returned 
OK, you're bored, and you make a joke. You say "thousand: hello". The employee doesn't check that you only said one word (hello), and starts to reply with "hello" plus then the next 999 words that he says, or thinks about, or has in memory, before putting the mic off. This is the bug that causes the problem. 
Those 999 words are unrelated. Most of it will be useless, remarks about the weather, request for coffee, lunch appointments etc. Some of it can be important information about the bank or other customers. A transport of gold, a customer is going to bring in $1m, the code for entering the bank or the safe, etc. 
There is no check if there are actually 1000 words to be replied. Plus you can do this request over and over again - the employee won't complain and nobody else is going to notice what is going on. 
There is one limit. You will only get information from this one bank employee, and only the stuff he talks or thinks about. Other employees are not affected. You cannot see what is on his desk or in his rolodex. (Analogy: only data in memory (RAM) is at risk; data on the harddisk which is not read into memory, and data from other programs and processes is safe.)
Doing this you don't know what information you will get, but doing it for a long time over and over again, you will get enough information to finally be able to break in without anyone noticing it. You can enter the bank after hours, open the safe, etc. This is the risk involved. 
The solution - check request and renew codes
If the employee would think for a moment he would only reply with one word and then disable the microphone so you cannot hear anymore what he is discussing. By making this check, you will stay connected and know that the employee has not hung up, but will not hear any random info anymore. In effect the employee needs new instructions on what to echo. This is fixed with the update to the latest version of OpenSSL. 
The bank will have to renew security keys for entering the bank and safe, because it is unknown whether someone has the old codes. 

A:

I'm going to have to use a few technical terms, but will try to keep them to a minimum and describe them.
Basic Intro to TLS & Encryption
You (a client) go to a website (known as a server) that uses encryption (the address starts with https://) to make it so no one but you and the website at the other end can know the content of the messages you are sending or receiving.  So when your messages are transported across computers on the internet they are encrypted -- they call this transport layer security (TLS) and it is one type of encrypted protocol.  One library that implements TLS is OpenSSL (TLS is the newer name for SSL, but both have the same intention -- encrypt network traffic on the internet). 
What is Heartbeat - the compromised TLS feature?
To set up a TLS connection there's a negotiation that's relatively expensive (it takes time).  Several messages have to be exchanged between the client and server before they can trust each other and safely send encrypted data back and forth. To have a quick and responsive experience (and minimize server load), you want to perform this negotiation rarely when possible, rather than do it before every single request (as you often will perform hundreds of requests in minutes with modern interactive websites).   Complicating matters, packets on the internet often get lost or corrupted.  The server may be overwhelmed with too many requests and need to drop its end of the TLS connection.  Or the client may have closed its browser window, so the server has no need to continue storing its end of the encrypted connection.
So in 2012 a proposal was implemented in OpenSSL (called Heartbeats) to send "keep-alive" messages between client and server to reduce the number of negotiations, when both ends still are using the connection.  The client asks the webserver periodically "Are you still there?" and the webserver (if it is still there), replies telling whether or not it is still there or whether future requests need a new TLS negotiation.
How the Heartbeat Extension works
The client sends a Heartbeat message consisting of a payload chosen by the client, as well as a brief header containing the size of the payload.  E.g., you could send a Heartbeat request of size 18 and text This is my payload (though generally it will be randomly chosen data).  The webserver gets that request, saves the content of the payload to the memory of the webserver, as well as the saving the size of the payload 18 that the client told it.
Then when the server sends a "keep-alive" response back to the client, the library reads those next 18 characters of memory starting from where it stored the payload and sends it back to the client (who checks that they received the right data back) and then the connection is kept alive. 
The Heartbleed flaw in OpenSSL
The fatal flaw (that has been named Heartbleed) is that the OpenSSL library never checked that the Heartbeat payload size corresponds with the actual length of the payload being sent.  A user is allowed to input any number up to 65535 (64 kilobytes) regardless of the true size of the payload.  If an attacker sends a Heartbeat request saying the size is 65535, but a payload that's only 18 bytes long the vulnerable server will store only 18 bytes in memory.  However, the response will start with those stored 18 bytes, but continue sending data from the next 64KB of memory back to the client.  This data could be usernames and passwords, private keys, username, HTML pages, random junk, or even the private secret that the webserver uses to establish its identity.   (The fix to OpenSSL implemented in 1.0.1g and later versions is essentially to perform sanity checks on the payload size as told by the client).
The attack can be repeated many times and in general will reveal different parts of the webserver's memory each time.  The attack can be performed anonymously in an undetectable manner for typical webserver configurations.  Typically, you only log IP addresses when you serve a web page, but this attack can happen early in the negotation process in vulnerable versions, before any webpage is served.
Attack on Clients
There is also a reverse version of this, where a user connecting to a malicious TLS server will trust the keep-alive request sent from a malicious server where the server lied about the size of its keep-alive payload.  This would cause the web browser to leak up to 64KB of information to the webserver.  (Granted this would be much harder to get usable information out of it and cannot be done anonymously and must be initiated by the client choosing to go to that webpage.  However, it still makes sense to patch OpenSSL quickly if you browse the web with an affected version.)
Remedy
The remedy for clients and servers that use OpenSSL is to update it.  System administrators running webservers that used the vulnerable OpenSSL library need to revoke their secret TLS keys and generate new ones (as well as invalidate long lived session tokens).  Clients should change their passwords on affected websites, which may have been leaked.   For clients, lastpass released a heartbleed checker tool that tests whether a site is (1) currently vulnerable, (2) previously tested to be vulnerable, or (3) likely vulnerable (using a unix/linux webserver and TLS, likely indicating use of OpenSSL which is primarly used on unix/linux systems) which may help determine whether you need to update your password at a given website.
SSH is not TLS so SSH keys are safe
SSH (which stands for Secure Shell) is a common tool on unix and linux machines, allowing users to remotely login to a machine and issue commands that are transported over the network encrypted.  SSH is an entirely different protocol from TLS (the answer says SSL, but that's just the old name for TLS -- the terms are often used interchangeably).  Even though OpenSSH (the most common implementation of SSH) and OpenSSL have similar names, your SSH keys are not vulnerable due to the Heartbleed attack.  
Only memory from the process that is doing the TLS encryption can be leaked through the Heartbleed attack. (A process is the computing term for a running instance of an application.) Modern operating systems implement process isolation that prevent processes from reading or writing memory assigned to other processes on the same system.  So contrary to xkcd.com/1353 you do not need to worry about all of your computer's memory being compromised, just the memory of the webserver process (or the webbrowser for the reverse form).  Secrets like SSH keys used by other processes (ssh, sshd, ssh-agent) are not being leaked because you also used TLS in a webserver.
For completeness, I should mention that this vulnerability should affect anything that may use the OpenSSL library to perform TLS, which isn't limited to webservers; e.g., FTPS servers (but not SFTP), Email servers, Database servers all may be vulnerable depending on the configuration.
More info about the vulnerable commit
It's also worth noting that the same person who wrote the vulnerable code that doesn't verify the size of the payload was the same author of the Heartbeat extension to TLS (described in RFC 6520).  Note the protocol did not specify a maximum size of Heartbeats response (while specifying a minimum size), but allowed it to be arbitrary length and let the payload size be described by a two byte header (allowing it to go up to 65535 instead of only 255 with a 1-byte header, which would have only exposed under 255 bytes of the webserver processes' RAM).  I honestly can't think of any reasonable reason to require a heartbeats payload that's longer than 16 bytes (128-bit), and if you wanted to be super paranoid you could let it be 32 bytes (256-bit).  With those limitations, it would be very unlikely to leak much usable information.  
It's also curious that the vulnerable code is dated to the evening of New Years' Eve 2011, which seems like a likely time to pass something under the radar or with less scrutiny due to the holiday.

