Until very recently online data transfer is supposed to be safe with the use of Secure Sockets Layer (SSL), Transport Layer Security (TLS). Well, this could hardly be thought that a little mistake in development could create dangerous bug like Heartbleed. This small code has made the entire open source based SSL development insecure (making 17% worldwide web servers vulnerable to hacking). A very recent analysis this April (2014) shows that web servers of some of the biggies (Yahoo, Amazon, Pinterest, Tumblr, Wikimedia and Wikipedia (to name a few only) have been affected by Heartbleed. Everything was apparently fine for last two years but on the first week of April it came to the fore that a malformed heartbeat (RFC 6520) request can fetch up to 64 kilobytes of data at a time from OpenSSL buffer memory which could include any sort of sensitive data. The data can be passwords or even server related private keys that help in further misuse of entire information stored in a particular web server. Within a few hours of disclosure of Hearbleed, reports came that The Canada Revenue Agency had faced a theft of Social Insurance Numbers belonging to 900 taxpayers. Now there could be lots of questions haunting our mind! Why was not this bug found earlier? For whose mistake millions of web servers have been exposed to this vulnerable situation? What can be the remedy and what can a common user do in such a situation? Let’s find out some of the answers already exposed in the matter of heartbleed.In June 2011 Apple declared to depreciate OpenSSL describing it as an outdated structure of the late 1990s. In connection to such allegations soon a particular feature was added in the structure via a Heartbeat code developed to keep secure connections alive and active. Without the knowledge of anybody the flawed Heartbeat feature was included in March 2012 release of OpenSSL. And unfortunately, it was enabled by default in the openSSL version 1.0.1 and 1.0.1f (inclusive).

How the heart bleeds?

Heartbleed is officially referred as CVE-2014-0160. Let me tell you one thing in clear, Heartbleed is not a problem with SSL or TSL technologies (not even with OpenSSL) that encrypt the online transactions for safety. It is a coding mistake. In any online transaction or data transfer two servers (computers) respond to each other’s request and the very response is technically specified as “Heartbeat”.It is made sure that each time the connected computers respond properly with similar quantity of data sent and received time to time in a transaction. In other words, the same volume of data has to be sent back as has been requested. Vulnerable situation occurs when there is inaccuracy in volume of data transferred. It is heartbleed that can force a responding server to send up to 64 kilobyte of data at a time while the request may be for less volume (say 16 kilobyte). So there is always a risk of sending sensitive data (login details of previous sessions, passwords and even server’s private keys remaining in the buffer memory of a server). A hacker can use heartbleed time and again to draw huge volume of data, without giving any knowledge to the people monitoring the security issues of the servers.

What’s the code that creates such insecure situation?

You may be thinking there would be numerous lines behind the malicious request sent to the servers! But in true sense as little as this code below can be the key to unlock all the ‘secure doors’: To explain things in simple way, we can find the function of the above code as follows: “Memcpy”= is a command that copies data “bp” = is a place on the server computer “pl” = is where the actual data the client sent as a heartbeat “payload” = the number that says how big the pl is Things work like this – In computer, there is no such thing as ‘empty’ memory. All the storage space is full with last saved data. But computer considers anything as empty as some data are marked as “to be deleted”. So next time a command comes to save any new data, the computer replaces all existing marked “to be deleted” data with new available data. In true sense, “bp” is full with ‘to be deleted data’ and that ‘to be deleted’ data would be overwritten with new data commanded as ‘to be saved’ immediately.In a simple and secure transaction memcpy takes data from pl and puts it in bp. It covers or replaces all the ‘to be deleted data’ in the bp. Technically, memcpy does what payload says – how big the pl (data sent to be placed in bp for replacement) is. So the client server gets back the same volume of data it requested through a heartbeat.

Now where is the problem?

The problem occurs when payload “tells a lie”. It means payload says the volume is 64 kilobytes while originally it is empty (0 kb). But computer takes it as 64 kb and memcpy creates a big 64 kb sized landing strip in bp (that has ‘to be replaced’). Unfortunately, there is nothing to be overwritten as pl is empty. But to respond to the heartbeat server has to send back 64kb of data (fetching the existing ‘to be deleted data’ which can be password, private keys and any other sensitive information in the memory that may be resting as left-outs of previous sessions) to client server or computer. So the ultimate result is breach in security. Hackers get the lollypop without knowledge of you or your supporting engineers employed to manage the security issues of your site. One fresh morning you find your site or server being hacked!

What is the Fix or solution?

The solution is not very much tough. But the point of concern is that much damage has been done before the solution came to the fore. A command that ensures calculation/consideration of actual payload does resolve the issue. It proves that the developers, who have not infused this simple line of code (noted below) in the OpenSSL structure, are highly responsible to incur such enormous damage. Let’s see what the fix code is: The above code says that once the payload is “0” then it is truly a zero-length heartbeat or the time the length is “64kb” (for example) then it is truly 64kb. Thanks to the developers who have brought out this fix and in the upper version of the OpenSSL there is no such bug attack possible. Here, once again we should remember that the lower versions or the version previous to OpenSSL version 1.0.1 through 1.0.1f was not affected by Heartbleed.

Now what can a common user do?

It is true that a common user can hardly do anything to prevent the data theft if not the technical experts handling your server have not upgraded the OpenSSL version that includes the fix code. But to console your heart against the “heartbleed” threat, immediately change your password as and when you get request from your server maintainers or yourself ask those authority if your server is safe against the “heartbleed”. So to conclude, it can be said that developers and the entire community engaged in keeping safety of the internet have to be very much careful in development of security essentials and use of ploys (codes and other encryptions too) to secure data transaction. In every case we need to be more careful in taking every step. We can only make sure that no other “heartbleed” issue arises. But “accidents” occurs but our consciousness help decrease in number of accidents.