Leveraging proprietary SSL to mitigate Heartbleed, MITM and other OpenSSL bugs

By Shibu Paul The Heartbleed bug has been creating chaos in the cyber security landscape and has affected about 500,000 sites and millions of users. The Heartbleed vulnerability – a small programming error caused by a student who has spoken of his regret at the incident - became public in the beginning of April. Since then, IT administrators around the globe have scrambled to patch web servers and to inspect and update their firewalls, mail servers, SSL VPN equipment, and just about every other device on the network that uses SSL. There are two main reasons why IT administrators have rushed to patch their systems. First, the Heartbleed bug has affected many popular websites to the tune of 17% of all SSL-enabled web servers worldwide, according to a survey from Netcraft, a UK-based internet services company. [caption id=“attachment_2143235” align=“alignleft” width=“380”]  Thinkstock[/caption] Today, about two-thirds of the world’s Websites use OpenSSL the encryption library affected by the Heartbleed bug, putting at risk more than half a million trusted websites. Secondly, the vulnerability is very dangerous. The flaw allows remote attackers to view up to 64 kilobytes of memory on a vulnerable server, enabling malicious users to access sensitive user data, such as usernames, passwords, and SSL private keys. The Heartbleed bug has existed on the Internet for the past two years. Weeks ago, when Heartbleed hit, some companies were at greater risk of attack while others had nothing to fear. Those spared were likely immune to the bug because their networking gear did not rely on OpenSSL to secure production traffic. Since a majority of websites are vulnerable to the Heartbleed bug, changing a password will not help much; as the website would have to update their OpenSSL software first in order to mitigate the threat. The vulnerability compromises the integrity of SSL encryption. While Heartbleed was not Internet security’s finest hour, it did create an opportunity to discuss why proprietary SSL implementations offer significant advantages over open source solutions. Developing a proprietary SSL stack is not easy. However, once the work is done, the security and performance advantages of proprietary SSL implementations are significant. With an effective vulnerability management solution, you can detect flaws that may exist in your infrastructure in order to analyze and improve them. One of the main reasons IT administrators are struggling to deal with Heartbleed is that they have to assess and patch a tremendous number of applications. As there are many applications running on different operating systems with different SSL libraries, administrators must spend several hours testing, patching, and retesting their applications. An easy way to safeguard vulnerable applications and avoid similar vulnerability is to terminate SSL traffic on ADCs. With the use of ADCs, it not only reduces the load on application servers, but it also lowers the cost of managing and updating SSL libraries. Administrators need not manage SSL certificates on each individual server, making it possible to eliminate the burden of patching all of their individual servers in the event of an SSL vulnerability outbreak like the Heartbleed issue. Most often, proprietary SSL is found on application delivery controllers (ADCs), the new breed of advanced load balancers that front-end servers to optimize application availability, performance and security. To gain the performance and scalability to support SSL encryption for large enterprises, Web properties and cloud service providers, SSL functions must be executed in the kernel – and doing so requires creating a streamlined SSL stack devoid of the extraneous protocols and features common to OpenSSL. When offloading SSL traffic with ADCs, it is important to ensure that SSL implementations are safe and they do not include vulnerable versions of OpenSSL. Many ADC vendors are striving to deliver secure, tested and validated SSL encryption, and apply best practices in network security in every step of product design, development and testing, so their products will not be impacted. While no solution can ever be fully secure, a proprietary SSL stack has another significant security advantage. Unlike open source solutions, proprietary SSL stacks are not publicly available, and do not give hackers the time and access needed to work out an exploit. In the event that a company finds a bug in its proprietary SSL stack, it can be remediated and fixed without the general public being made aware of the vulnerability. In the case of both Heartbleed and MITM vulnerabilities, businesses that used ADCs and selected ADCs with a proprietary SSL stack – were largely unaffected. Using servers for SSL leaves businesses vulnerable, hinders performance and complicates remediation due to multiple OpenSSL versions. While a load balancer can improve performance, most rely on multiple versions of the OpenSSL standard and remain vulnerable to bugs such as Heartbleed and MITM. In contrast, top-tier ADCs with proprietary SSL stacks significantly reduce exposure to vulnerabilities and at the same time substantially reduce effort required for remediation. While it is said that security often comes at the expense of performance, in the case of proprietary SSL, businesses simultaneously gain superior security and superior performance. (The author is regional sales director – India, ME and SEA, Array Network)