What an IT administrator should know about Heartbleed

This is a quick summary of what every IT administrator should know about the Heartbleed bug. It may become obsolete as investigations progresses.

How Heartbleed works

See simplified explication here.

How did it happen

The bug was introduced by Dr. Robin Seggelmann, as part of his university work. He was implementing the TLS heartbeat feature.

In his code posted on new year’s even (2012), he forgot to check validate the length of a variable.

The bug was not spotted by the reviewer and merged into OpenSSL.


About two third of the internet uses OpenSSL, just about 17% of servers would be actually exploitable. Estimated to about 500,000 sites, including banks and other service providers.

What is vulnerable

  • OpenSSL 1.0.1 to 1.0.1f
  • Nginx with SSL and Apache with SSL (However, according to Steven Gibson in  Security Now #451 the exploit would not work in Apache due to the way Apache manages memory. At least not to retrieve the private key)
  • Android 4.1.0 and 4.1.1 (disabled on newer versions). It could be exploited by a malicious server. Implications are not known yet
  • OpenVPN, need to check the versions(Note that there is no exploit known again OpenVPN using TLS authentication)
  • Some Cisco and Juniper products
  • Many home routers, for Tomato firmware users, an update is already available


According to the challenge organized by Cloudflare, it takes between 1GB and 10GB of TLS heartbeat malformed traffic to piece together a server’s private key. It’s quite a lot and may be identified.


Security researchers have inspired graphic designers.

Security researchers have inspired graphic designers.

Major companies, companies such as Google and Cloudflare spread the word in secret before the bug was made public. It means that they probably were not exploited for this major companies.

However it seems to have evidences that some servers were tested for the vulnerability before it’s discovery by security researchers at Google.

Because we cannot know really what happened, it is possible that server’s private SSL keys were leaks among other secrets, that’s why it’s recommended to change your passwords.

It also raises the the fear that stored web traffic (for example by the NSA) could be decrypt stored traffic. It demonstrates the importance or Forward Secrecy(aka PFS) to protect past traffics against decryption.

Actions to take

To not take any risk, if you run a secured site, you are supposed to:

  1. Update OpenSSL package or recompile it without TLS heartbeat
  2. Restart all services using OpenSSL, such as Nginx and OpenVPN
  3. Re-issue SSL certificates
  4. Revoke old certificates
  5. Ask users to changes their passwords

Updating your IDS would be a great idea! Also, if you didn’t do it yet, configure your server for Forward Secrecy(aka PFS).

For web users, enabling certificate revocation check in you browsers could protect against leaking private keys, at a little performance cost.


The fallout of such a bug could actually be worst than they are. The main problem raised by Heartbleed is the lack of means in the OpenSource communities.

Let’s put it this way: 2 people introduced a bug by an honest mistake and it took 2 years for security researchers to uncover it. Having that in mind, the NSA has a team about 1000 strong looking at OpenSource updates and looking for vulnerabilities in general.

OpenSSL is commonly referenced as a nest of outdated coding practices, for example, to compile it for Windows, you need a 20+ years old C compiler on which you have to disable many warnings. We got there because OpenSSL was never meant to be what it is now, it just grew over time and now very few people have a precise understanding of how it works. An audit of the library would be actually a big and very expensive challenge.

The industry leaders may need to step up to either:

  • Refactor OpenSSL
  • Create “from scratch” a replacement library potentially introducing many new bugs.

UPDATE 2014-04-23:

As ArsTechnica reported, OpenSSL has been forked by the founder of OpenBSD. The fork is intended to be a cleaner version called LibreSSL. It’s author said they where able to remove 90,000 lines of code without affecting the core functions of OpenSSL. Let’s wish them good luck in making the Web a safer place!

UPDATE 2014-04-25:

The industry leaders have announced that they will sponsor OpenSource projects with priority to OpenSSL. See detailed article.

We can be expecting more researchers to look successfully for vulnerabilities, let’s hope without too much consequences.


Leave a Reply