# 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?

• Heartbleed allows an attacker to anonymously download a random chunk of memory of the server. This means they can get unencrypted passwords, and low-level encryption keys that protect your account... not to mention that an attacker might be able to access any part of the website (or data that you post into that site) – goodguys_activate Apr 10 '14 at 5:27
• You could let them watch youtube.com/watch?v=rE5dW3BTpn4 – Darsstar Apr 10 '14 at 5:59
• The easiest way of explaining: xkcd.com/1354 – Veda Apr 11 '14 at 7:45
• I liked the explanation by Maciej Cegłowski on the Pinboard blog: blog.pinboard.in/2014/04/heartbleed_and_pinboard – alexwlchan Apr 11 '14 at 10:15
• Same as the last 50000 Windows unchecked buffer length attacks, only this proves it's not just Windows. – Peter Wone Apr 11 '14 at 13:18

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.

• I would say even a school kid can understand.... Damn i can only vote once... – Dungeon Hunter Apr 10 '14 at 17:52
• The important sentence is "Some may be information about the bank or other customers." If that one employee is multi-tasking and dealing with queries from a number of people, he could be telling you their data, and in the same way telling them your data. Unfortunately you have no idea what he's been saying to whom and who he might have given your data to. – Andrew Leach Apr 15 '14 at 6:21

The most "non-technical" explanation I found.

• I'm a technical person and also a visual person. I can say that this is the best explanation of Heartbleed yet: concise yet contains everything the anyone needs to know to get the point. – Kevin Li Apr 17 '14 at 4:36

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.

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.

• Thanks for the excellent explanation, plus making clear that SSH is not affected. The conspiracy twist at the end - the icing on the cake! – SPRBRN Apr 10 '14 at 10:42
• -1: this is a horrible answer to the question as stated. There is no chance that a non-tech-savy user would listen to, let alone understand even 10% of this. – Michael Borgwardt Apr 11 '14 at 10:57
• @MichaelBorgwardt Probably true, but for someone who is technical but has no idea about web technology it is excellent – Richard Tingle Apr 11 '14 at 12:57
• Yeah, this is a great explanation of Heartbleed, but not for a layperson. – Lightness Races in Orbit Apr 13 '14 at 19:19
• This should be the accepted answer, very ondepth and informative... Hell my 11yr old daughter read it and understood what he was saying... – ehime Apr 14 '14 at 15:34

In really plain English: the attacker says they're sending a packet of size "x" and asks the server to send it back, but actually sends a much smaller packet. The OpenSSL library trusts the attacker, sends back the small real packet as the start of the reply, and then grabs data from memory to fill out the reply to the expected size. This could be any data the server has handled recently, and often contains sensitive information.

This example dialog - perhaps you are both characters, or you get them to ask the questions of you:

Q1: What's your favourite colour (1 word)
A1: Blue

Q2: Where did you last go on holiday (2 words)
A2: To France

Q3: What car do you drive (1000 words)
A3: Vauxhall Astra. Cheeseburger. Tomorrow I'm driving to London. I like cake. Ohhh a squirrel. My PIN is 1234. I like chickens. SPAAAACEEEE. Last night I ate spaghetti. BUD WEIS EEEEERRRR. etc etc etc

That last chunk is mainly garbage, but there might be a few good things in there.

• That genuinely was my train of thought... Worrying or what! – Rich Bradshaw Apr 15 '14 at 16:39
• Should the third question be Q3 rather than Q2? – daviewales Apr 19 '14 at 12:51

Here's an attempt to use almost no jargon at all.

When you connect to a "secure" website (one with a green bar and padlock icon), your browser and the website perform a bit of mathematical hocus-pocus and you both end up with a secret key - like a very long, random password - with which you can send each other encrypted messages.

As you browse around the site and click links, it would be very expensive to redo the whole hocus-pocus each time so the website and browser just carry on using the same key for a while. Since the website doesn't want to keep a list of every single key that every single visitor has ever used, a protocol called heartbeat was invented. As long as you're still browsing around, every now and then your browser will send the website a message saying HEARTBEAT, which means "I'm still here, keep hold of my key". The website replies something to the effect of "roger that". If the website doesn't hear any HEARTBEATs from you for a while, it presumes you've gone on to some other site and throws away your key to make space for new ones.

Actually, heartbeats do one more thing. You can send any text you like along with them and the website will reply with exactly the same text. Why it's done this way is not quite clear to me, I suppose it's so that your browser can check if something funny's going on (like the wrong text coming back, or texts coming back in the wrong order) and let you know that someone may be doing something nasty.

So your browser every now and then sends a message like "HEARTBEAT, text with 5 letters, HELLO" and the website replies "roger that, 5 letters, HELLO". The text can be pretty much anything, like the current date and time. You could send a poem if you want to.

The heartbleed bug is that if you send a message like "HEARTBEAT, 1000 letters, CHEESE" then if the website is using a program called OpenSSL to do the encryption it goes badly wrong. And OpenSSL is kind of the most common program used to do encryption on the internet. What it should do is notice that CHEESE has 6 letters, not 1000, and complain. Instead, it reads your message and writes it to somewhere in its memory. Then, it replies "roger that, 1000 letters, ..." and starts reading out the next 1000 letters from its memory starting at wherever it stored your CHEESE. So you get to hear whatever the next 994 letters in its memory are, and this could be literally anything. It could be the website's secret keys. It could be a poem. It could be other customers' passwords and credit card details. It could be a picture of a cat. It's completely random but every time you send a HEARTBEAT message like this, you get to see a different random portion of the website's memory so if you just repeat your HEARTBEATs often enough, you're quite likely to hit something interesting sooner or later.

The worst that can happen is that you get back the website's master keys, the ones used to start off the hocus-pocus whenever a new visitor comes to the site. If you do this, you can in theory read everything that everyone is doing on the site, as if there were no encryption at all. Whenever someone logs in, you'd get to see their password in the clear. That's not a nice thing to happen.

• If an attacker steals the "master keys" from the web server, they must still either a) capture all the traffic to and from the web server or b) set up a man-in-the-middle attack that passes all traffic to their own "proxy" server instead, to be able to read everything that everyone is doing on the site. There will still be encryption from the end user to the web server (m-i-t-m or real), and the users communication will be safe from everybody except for the attacker who has stolen the "master keys". – MattBianco Apr 10 '14 at 11:11
• True that (and though I didn't mention it in the text, +1 reason to use perfect forward secrecy too). For the target audience mentioned in the original question, I'd need to think hard about how to explain mitm attacks in this context. – Bristol Apr 10 '14 at 11:52
• Why it's done that way is so you have a clear indication that they have acknowledged your heartbeat. You've given them some unique payload that they give back to you but would not have known from any other source, and you can say with certainty that the connection is still alive. – corsiKa Apr 16 '14 at 21:52
• @MattBianco Unless they've actually stolen the plaintext root username and password, in which case they just need to ssh in and the server is theirs. – corsiKa Apr 16 '14 at 21:54
• @corsiKa, how would they steal the root password? And why would root be able to log in with ssh at all, and with password authentication? That's just stupid! – MattBianco Apr 17 '14 at 12:16

I'll use one two three technical terms, "heartbeat," "bug," and "webserver." I hope that won't scare off your non-technical friends.

When computers exchange data over the internet, sometimes it is useful to know if the other one is still listening. In many places, there are provisions to do the equivalent of asking "Hey, are you listening? Can you tell me what I just said?" In different contexts, there are many different names for such techniques that sometimes even turn up in mainstream media---"echo" is one, "ping" another, and the one that has a serious bug in a very widely used piece of software is "heartbeat." This particular "heartbeat" scheme is not actually used in many applications, but because the general idea can be so useful, many computers allow it.

The problem is that one piece of software most webservers use has a bug: Depending on just how the "What did I just tell you?" is asked, it can be tricked into trying to repeat more than what the other side had actually sent, filling in the rest with random things the webserver happens to know. By asking in such a tricky way, one can get webservers with this bug to tell almost anything they know about, including user passwords and (from webservers that handle such information) sensitive data like credit card numbers, email contents, etc. And it doesn't stop there, even the secrets with which other computers could impersonate these webservers are at risk.

This is not limited to webservers, but that's where anyone using the internet comes into contact with it. But computer security people have their hands full now with lots of computers and lots of different software that may be affected.

• This is pretty good, but I would say 'When answering the question "What are the last thousand things I just told you?" after telling it only 1 thing, it carelessly answers with that one thing plus 999 other random things it was thinking about.' – AShelly Apr 10 '14 at 21:18
• Sure. Trouble is, if I try to include all such details, before I know it I'd be trying to explain about bits and bytes and hexadecimal counting (why 999? why not 0xFFFF?)... – pyramids Apr 10 '14 at 21:51
• Right, but without describing an invalid length request, it seems like every innocent heartbeat leaks data instead of just the malicious ones. That seems like a big distinction, but one that's not too technical. (leave the specific numbers out if you want.) – AShelly Apr 11 '14 at 15:07
• @AShelly I've edited the answer to show that not every heartbeat leaks data, albeit still not talking about numbers. Of course, now I wonder if your original proposition was better after all! – pyramids Apr 11 '14 at 16:27

When you visit a webpage which uses "https", the connection between you and the webserver is encrypted. This protective layer is called SSL or TLS. An underlying component of this implementation has a security-problem with it - causing the server which serves a webpage to "leak data" (i.e. disclose memory contents to an attacker). There are some constraints on how this data is leaked, but it is very serious and could expose all kinds of data on the vulnerable server.

Here is a technical video which shows an example of data-leakage from a vulnerable server and also shows how to prevent data from being leaked: https://www.youtube.com/watch?v=UjkK22VBzjA

New analogy:

Imagine you're calling the bank to ask if one of its offices is open. You get a machine on the line (the infamous "for English, press 1" lady) and it asks you how many banks you want to know the hours for, and which banks. You then say you want the hours for 65,000 banks, but only give it the code for a single bank. The machine thinks that it needs to give the hours for 65,000 banks, but since you only give 1 bank code, it fills the rest with whatever it can find: bank statements from random accounts, credit card numbers and codes, a picture of the key for the safe, the discussion the manager has at the time with his doctor,... It doesn't realize that that other data is irrelevant, and that you should have only gotten opening hours for 1 bank.

Imagine your bank has a system where you can send a secure request for the current pincode of your debit card, and the system returns a pincode and a bank card number. This system gets an update where you can send a list of cards to reset.

You send a request for a list of 65,535 debit cards to reset, but only pass 1 card number. Instead of returning just that single card or throwing an error, your bank sends back the existing codes for 65,534 other cards from other random users.

• If you're downvoting, at least explain why so I can edit it if needed. I personally think this is a similar concept: you send a malformed request to the server, and the server sends back data it shouldn't send back. – Nzall Apr 10 '14 at 11:28
• Not my downvote, but your answer does not come close to explaining what is happening. Maybe this answer will work for your grandmother, but this is a different audience, even if a non technical answer is requested. – SPRBRN Apr 10 '14 at 11:40
• The question is "I want to explain to my non-techie friends what Heartbleed is". The OP wants a non-technical explanation for people who are not good with computers. In this case, you don't get that far by just explaining the concept. You need an analogy. And one of the best analogies I could create with the same scale and the same risk for affected users is using bank account data. I realize that it's woefully inadequate for the regular audience, but I believe it's far more appropriate for someone who doesn't know what SSL, a heartbeat or memory is. – Nzall Apr 10 '14 at 11:45
• OK, read Jimbob's answer. Then fix yours. Let's say the request is handled by a person, not a computer. The bank employee handling this does not send the codes of those 64k cards, but it sends anything that (s)he is handling, like a note from the manager, a phone conversation, a joke, etc (but only for that 64k). Anything that is handled by that person. By doing this over and over again, you can get an idea of what is going on, and how procedures work, what security procedures especially, and from there on you can go in and pretend to be that bank employee yourself. – SPRBRN Apr 10 '14 at 11:50
• Another problem with your example is that it is about an actual request, while the heartbeat is only a phonecall to the bank to see if it's open. – SPRBRN Apr 10 '14 at 11:58

Imagine a book you never read and then you don't know the content because the book is closed, the heartbleed bug, is just a way to open a page randomly and being able to read the text, from the book. after extracting enought information you're able to replicate the book and replace it on a shelter without anybody being able to notice. The book being either your computer or your server.

That would be the most simple explanation I would give to non technical persons.

If you want a more precise version, let say you have a book closed with an electronic lock that book is your personal diary. You're the only one that have the key, so you're the only one to be able to both read and write it.
Too bad you electronic lock is defective and allow someone who know the trick to unlock it for 2 seconds.
By doing that more and more you will be able to read the whole content and eventually to modify it afterward.

It's like this.

You're walking along the street and, passing the entrance to a bank, you encounter an autistic savant on his way out. He seems like a nice guy, but you're not, and you know you can use him for nefarious purposes, because you've watched enough movies to have learnt that savants can retain and repeat amazing amounts of data and are generally pretty observant, too.

So, you ask him for the time. He tells you the time, but can't help but keep talking. He tells you every bank account number and password that went past his eyes and ears whilst he was in there.

That information is now yours. All you had to do was ask for the time because, by virtue of his condition, the savant was unable to stop himself from telling you more than he was supposed to. What he doesn't realise is that, by asking for the time with your nefarious purposes, since you knew what was likely to happen, you asked for more than you were supposed to as well.

Poor chap.

• -1 Doesnt explain how it gets the information – user36976 Apr 13 '14 at 19:27
• @Nick: It's an analogy. Without technical detail. As requested. If you want the technical details then they are available all over the internet. – Lightness Races in Orbit Apr 14 '14 at 6:07

## protected by Rory Alsop♦Apr 11 '14 at 13:53

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?