What Can We Learn from the Heartbleed Bug?

The heartbleed bug was made possible with the introduction of the TLS Heartbeat Extension about three years ago (DTLS, but we will call this TLS for simplicity).

10 April 2014


UPDATE: For a Heartbleed update and recommendations for Intralinks customers, please visit here.

There was a flurry of press activity last night regarding the Open SSL bug, also known as the Heartbleed Bug, that got all operations and security people scrambling to fix the only real compromise of SSL in recent memory. This is bad news on many levels but, most importantly, the private keys protecting the data on the public Internet could have been stolen from web sites, which means the certificates of all sites affected must be re-issued.

Secure Sockets Layer (SSL) is familiar to most people as the security “S” in HTTPS address bars, usually accompanied by a small lock symbol and used when entering sensitive information on a website, such as credit card details. The Heartbleed Bug has affected 17.5% of all SSL-enabled web sites, or around half a million organizations globally, including Twitter, GitHub, Yahoo, Tumblr, Steam, DropBox, HypoVereinsbank, PostFinance, Regents Bank, Commonwealth Bank of Australia, to name just a few. Even the anonymous search engine DuckDuckGo is affected, according to Netcraft.com. The worst part – it did not need to be this way.

The Heartbleed Bug was made possible with the introduction of the TLS Heartbeat Extension about three years ago (DTLS, to be exact, but we will call this TLS for simplicity). The problem the TLS Heartbeat Extension was trying to solve was creating an inexpensive heartbeat detection for protocols that, unlike TCP, do not offer reliability in delivering data packets (a heartbeat detection is simply a way to confirm that the recipient of a secure communication is still active). These protocols, similar to UDP, have had to re-negotiate the connection every time just to check if the other endpoint is alive. This renegotiation process is probably the most costly and time-consuming step in network protocols and the TLS Heartbeat Extension was meant to resolve this problem.

How did the Heartbleed Bug Occur?

We only know some of the issues that make the Heartbleed Bug possible. First, the new heartbeat checking feature allows up to a 16 kB payload as a response to a heartbeat detection request (some sources claim that 64 kB of data can be stolen, perhaps suggesting that up to four repeated requests yield data).  Certainly this feature has contributed significantly to the problem. What was supposed to be in that response – a very simple ‘Hi, I am alive and kicking’ – somehow grew to allow meaningful amounts of data to be transmitted.

This brings me to my second and perhaps more important point - people deploying feature-rich technology without fully understanding the implications. In my opinion, bugs are a fact of life – and organizations need to operate with this firmly in mind. In this case, companies should have asked themselves if they really needed the TLS Heartbeat Extension. I venture to say that, on the vast majority of affected sites, users never took advantage of this feature. But the attackers certainly did.

At Intralinks, we take an extremely conservative approach to security and access control and, as a result, our platform is not directly affected by the Heartbleed Bug. Hopefully, one positive outcome of the Heartbleed Bug will be that security professionals will be given a platform and will be able to justify policies requiring thorough review of core technologies before deployment, and related expenses.

With regard to the Heartbleed Bug, applying the fix alone is not enough. Anyone affected must assume that all SSL certificates have been compromised and need to be revoked. All users of those sites must change their passwords as well. There may be some other remediation steps that are needed, but that can wait for another time.

Which reminds me, I’ve got to run – all six of my Yahoo account passwords need changing.

Mushegh Hakhinian

Mushegh Hakhinian

Mushegh Hakhinian represents Intralinks at the Cloud Security Alliance SME Council, is a certified information systems security professional, and is a frequent contributor to industry publications. Prior to joining Intralinks, Mr. Hakhinian lead security functions at a multi-tenant online banking service provider and an international bank.