Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

“Heartbleed” in OpenSSL: Act now! We can help you!

Posted on: 21 April '14

The Secure Sockets Layer (SSL) is a specification used to protect sensitive data while communicating over the internet. In today’s context of MoSAICS (Mobility, Social, Analytics, Infrastructure, Cloud and Security) stack – the 3rd Platform, this is the standard for secured communication. With the shelf-life of products diminishing, continuous integration, agile development and infrastructure, your communication across these platforms ought to be secured and no one else should be able to see what is being sent back and forth. This specification has an implementation bug particularly in OpenSSL given that everyone has got access to the source code.

First, I’d like to clear something that has been making me cringe every time I hear someone say the heartbleed virus has attacked. It is not a virus. It is a vulnerability. A vulnerability is a loophole inherent in an already established piece of security system. And it does not attack. This vulnerability can be exploited, and potentially impacts a good 70% [Src: Internet research] of the WWW today.

In networking, when any two appliances require to communicate, they tend to use either TCP or UDP protocols. TCP (Transmission Control Protocol) is a perfectionist protocol, where the Packets (deliberately assuming that the reader knows the packet analogy) are accounted for and if there are any packets missing or out of order, TCP re-sends the missing packet or assembles them in the right order at the receiving end. UDP (User Datagram Protocol) is not a perfectionist protocol but a get-it-done protocol. It transmits packets without error recognition or order synchronization. To make networking secure, all forms of communication using either of the protocols are encrypted, mostly using SSL (Secure Sockets Layer). While TCP has a method of keeping communication methods alive with KeepAlive function (used for error checks!), UDP does not have the same requirement because it was not required where error checks are not required. Later on, a method to mirror the function of KeepAlive was added to UDP called HeartBeat (somewhere in 2012). The HeartBeat function involved an end point client machine sending a ping to a server to keep a communication alive and expecting an acknowledgement. The acknowledgment was also based on the length of the acknowledgement expected by the client machine ping. Now you know what Heartbeat does. The vulnerability of HeartBeat lies in this acknowledgement and the length of it. If asked for a longer length than required (up to 64KB), the server send the response including the memory content kept in its RAM up to 64 KB which would also include data about the recent transactions which have been made by the server (all kinds of data including password changes, SSL encryption key handshakes etc). The involuntary disclosure of information stored in the memory is called, very cleverly if I may add, HeartBleed.

The key thing to keep in mind is that the HeartBeat function was added in the OpenSSL implementation, versions of 1.0.1 to 1.0.1f. Other SSL implementation methods do not have this vulnerability. Given that this vulnerability has been around for two years, it is important to change existing credentials of users, and make sure the OpenSSL implementation is patched and SSL certificates are re-issued. The extent of damage is yet unknown. But preparing for the worst is the best way to go forward!

To resolve this issue and close the Heartbeat vulnerability, Mindtree has been following two methods. Mindtree engineers have been working round the clock in following emergency change protocols to ensure all the servers/network devices (basically any end point communication device using OpenSSL) are patched, the versions are upgraded and more importantly, renew the SSL certificates so that the encryption keys are changed. On the other hand, Mindtree has been asking end users to use specific extensions on their client browsers – Chromebleed /Foxbleed (for Chrome and Firefox browsers respectively) which warns users on the sites that still have the vulnerability alive so they can change their credentials in those sites. We can extend this professional help as part of our Managed Security Services (Unified Threat Management).

Special thanks to my colleagues Vijaya Rajan Shankar (for research and input to the blog), Mansoor Poolakkal (for sharing potentially affected sites) and Mark Masuelli (for sharing the remediation report).