The Heartbeat Bug

By now you have heard about the Heartbeat security issue with OpenSSL.  Here we are going to describe what exactly the problem is and how it affects Apache and Nginx web servers.


Most web servers use OpenSSL for encrypting and decrypting user SSL sessions.   OpenSSL is open source software that provides the cryptographic algorithms needed to do that, plus it can do such tasks as convert digital certificates from one format to another and create X.509 certificates.

In February this year, OpenSSL released version 1.0.1f which would seem to coincide with an academic paper that pointed to another security issue with OpenSSL.  That has received far less coverage in the international media than the new bug, known as the Heartbeat bug.  The 1.0.1f version released in February has the heartbeat bug.  OpenSSL this week patched that.

The Heartbeat bug was uncovered only a few days ago by two different security researchers working independently.  It has to do with the heartbeat used to maintain a sticky SSL connection without which a user would lose their session information going from one page to the next.  That would cause the web server and browser to have to renegotiate the session for each page.  That means the web server then would have to use its certificate to generate a new shared secret to encrypt data using SSL (now called TLS) between the web server and the user’s browser.

The bug in SSL can be illustrated by looking at these two code snippets from the OpenSSL c-language source code.

In the first data structure we see a field called payload_length.


The next graphic shows the actual heartbeat data structure taken from the TLS standard.  There an integer gives the length in bytes of the heartbeat data and the heartbeat data.


The problem is that OpenSSL uses its own value for the length of the heartbeat data structure and not the value from the SSL3 data structure when the heartbeat is send to the browser.  Thus it can be exploited by modifying that value to point to memory beyond the range of the heartbeat data record.  That would give a hacker the ability to read other parts of the web server’s memory.  If a hacker tried this enough times (Memory storage location is randomized to prevent this kind of attack.), they could retrieve the server’s signed certificate plus, in this photo published by the researchers who uncovered the bug, a user’s password.

In the graphic the user’s Yahoo password is blocked out in orange.


Apache mod_ssl

Apache uses mod_ssl for SSL encryption.  That module uses the OpenSSL software.

If you use the mod_so in Apache then to fix this issue all you need to do is download the patched version of SSL.  Mod_so allows the OpenSSL library to be loaded dynamically, meaning at runtime.

If not, you will need to download the OpenSSL source could and recompile Apache, because in that case mod_ssl is linked statically.

Nginx ngx_http_ssl_module

For Nginx there is no need to recompile your web server, as you can see right in the source code shown below Nginx that the OpenSSL library is loaded dynamically, because the programmers left comments there saying that.  But you will need to upgrade OpenSSL.


How to know if you have the affected version

The bug affects OpenSSL versions 1.0.1 to 1.0.1f.  You can login to the server and type “openssl version” and it will tell you what version that you have.

The other thing you can do is to download this Python code and to try the exploit on your web server.  Of course that would be just for academic interest, since you can check the OpenSSL version that you have as explained above.

In the graphic below, I ran the Python code against and  In both cases it reported that the servers were not vulnerable.  If they had the version of OpenSSL with the bug, it would have shown part of the machine’s memory.


What else should you do?

Finally, you need to obtain new web server certificates following the assumption that yours could have been stolen.  If someone has stolen your web server certificate, they could use it to replay old SSL sessions if that have captured that encrypted traffic for that one session.  And as we see with the Yahoo example, they could retrieve encrypted user data in cleartext, by using the Python code shown above or any of the multiple variations circulating on the web now.

One item which has not been discussed too much in the technical literature and blogs is how this affects hardware and programming languages.  Python, Ruby, Java, and other languages all have OpenSSL modules.  Presumably they would have this issue too.  The only thing we can do is to keep reading the security blogs and see if any researcher publishes any findings about that.