In assessing SSL vulnerabilities, it is important to examine both SSL used for securing live Web traffic and SSL used for securely managing servers, load balancers, application delivery controllers (ADC) and other networking elements.
SSL for live Web traffic commonly occurs on servers, load balancers or ADCs. Of these three, servers are the most vulnerable and deliver the worst performance when tasked with SSL encryption. Not only do servers use OpenSSL, they often use multiple versions of OpenSSL and, as a result, create environments that are difficult to remediate in the event of new vulnerabilities. In addition, servers rely on general-purpose hardware to perform compute-intensive application networking tasks such as SSL, making them unsuitable for enterprise or service provider-class workloads.
Using load balancers to offload SSL from servers does improve application performance, however; the approach does little to address vulnerabilities. Like servers, common load balancers use OpenSSL to avoid the expense of developing a proprietary, high-performance and security-hardened SSL stack. On the one hand, with load balancers, there is a better awareness of OpenSSL versions in use, making remediation easier in the event of new vulnerabilities. On the other hand, typical load balancers are generally insufficient for enterprise or service provider-class workloads.
Professional-grade ADCs not only provide superior capacity (millions of SSL connections), they are also far less vulnerable as compared to solutions that use OpenSSL. Because they use a buttoned down SSL stack that runs in the kernel, ADCs enable enterprise and service provider-class performance without sacrificing security. While no solution can be 100% immune, professional-grade ADCs are significantly less likely to be affected by vulnerabilities introduced by OpenSSL. As an example: for Array customers, MITM and Heartbleed had zero impact on security for production SSL traffic.
In contrast to SSL used to secure live Web traffic, connections opened to manage networking equipment are almost always secured using OpenSSL. This is because performance and scalability are not required to support a limited number of management connections (often just one). That said, some networking vendors are more affected than others when it comes to OpenSSL bugs such as Heartbleed and MITM. Those that are less affected tend to place a stronger emphasis on security as a practice and take a more cautious approach when using OpenSSL.
An example would be: rather than adopting the most recent version of OpenSSL as soon as it becomes available, smart vendors take a “if it isn’t broken, don’t fix it” approach. In other words, smart vendors evaluate the benefit or necessity of new features vs. the risks of adopting new versions with unproven track records.
In contrast, vendors that were affected by Heartbleed tend to adopt new versions of OpenSSL as soon as they become available, without considering security implications. As a result, they expose themselves to two undesirable outcomes. First, the unnecessary risk of adopting unproven implementations that offer no advantages for secure management and second, the proliferation of multiple OpenSSL versions in the field and corresponding difficulty in remediating vulnerabilities as they occur.
For Array and its customers, Heartbleed had zero impact on SSL connections used for management, and MITM had minimal impact. In the case of Heartbleed, Array dodged the bullet because the version of OpenSSL we use to secure management connections was not affected. In the case of MITM, the version of OpenSSL Array uses for management was affected; but because only a single version of OpenSSL is used, customers can simply use SSH for management while they wait for a patched version of ArrayOS.
In the aftermath of Heartbleed and MITM, best practices for preventing the next OpenSSL-related vulnerability are starting to emerge. A somewhat obvious strategy is to consider the nature of your applications and Web traffic; if they are mission critical, a professional-grade ADC may be in order. Even if you may not need the scalability and advanced features included with this class of product, the security benefits alone may be worth the price of admission. A second strategy may be to engage with vendors to determine if they take a cautious and deliberate approach to security and instances where they use OpenSSL.
While perfect security remains a constant challenge, Heartbleed and MITM present an opportunity for everyone to better understand the nature of OpenSSL and implement some simple and straight-forward strategies (security as a best practice for end users and networking vendors) that can help reduce an organization’s exposure to future vulnerabilities.
Paul Andersen is the Director of Marketing at Array Networks (www.arraynetworks.com). He has over 15 years’ experience in networking, and has served in various marketing capacities for Cisco Systems, Tasman Networks and Sun Microsystems. Mr. Andersen holds a Bachelor’s Degree in Marketing from San Jose State University.
Preventing the next Heartbleed & MITM
Recently, OpenSSL bugs including Heartbleed and Man-in-the-Middle (MITM) received considerable press due to the widespread use of SSL to secure virtually everything on the Web, including ecommerce, social media, business applications and online banking. While many businesses and networking vendors went into damage control mode, Array Networks and its customers calmly weathered the storm. In the following paragraphs, we will examine how Array avoided exposure to Heartbleed and significantly mitigated exposure to MITM, and discuss best practices for implementing SSL in a manner that mitigates as-yet-unknown OpenSSL vulnerabilities.
Most Popular Stories
4th Annual Mission 500 Hockey Classic
February 21, 2019
Security Career Expo
March 7, 2019
April 10-12, 2019
26th Annual ASIS Toronto Best Practices Seminar
April 17, 2019
Security Canada East
April 24, 2019
Security Canada Ottawa
May 8, 2019