In this article, we will show you how to fix the OpenSSL Heartbleed security flaw. OpenSSL Heartbleed has been recently discovered by security researchers. This security flaw is as a result of a software bug in the SSL/TLS protocol implementation of the OpenSSL library.
Heartbleed is catastrophic at many levels:
- It’s easy to exploit.
- The majority of network devices and servers over the internet rely on OpenSSL for secure communication.
- The information leaked to an attacker is of Grade-A quality: usernames-passwords, session keys, long-term keys and event unencrypted user data.
The Anatomy of HeartBleed
Before we get into how Forum Sentry mitigates the risk of Heartbleed, let’s take a closer look at how the Heartbleed bug can expose sensitive information.
The security flaw specifically exists in the TLS protocol implementation of the OpenSSL library. TLS is a successor to the older SSL protocol. The OpenSSL library versions that are vulnerable to this flaw range from OpenSSL 1.0.1 to OpenSSL 1.0.1f.
TLS (https) is used to establish a secure channel between a client and a server. After the secure channel is established, the TLS protocol standard provides the client an option to ping the server with a “Heartbeat” message and then receive a response. This “Hearbeat” message checks to ensure an idle channel is not terminated due to inactivity. For example, the two parties may not have exchanged data for a long time, which may result in termination of a TLS channel due to inactivity. Hence, a “Heartbeat” message exchange results in small chatter that keeps the TLS channel active between the two parties.
In a clean and properly working scenario, the client would send a “Heartbeat” message over the TLS channel that consists of two parts, the size of the message and the actual content of the message.
The figure above illustrates a “Heartbeat” message flow between the client the and the server.
Please note that in the real world, the message content, as shown above, is not the actual representation of the Heartbeat exchange. We are picking arbitrary message content to simplify the example. The following steps describe the interaction between the client and server:
- The client sends a message of size 5 bytes and the data content “HELLO”. If you count the number of characters in the word “HELLO”, the number corresponds to the 5 bytes included in the message (1 byte = 1 letter).
- The server receives the message content “HELLO” and stores it in its memory so it can send it back as a “Heartbeat” response. There is also additional data stored in the server’s memory from other TLS channels that the server may have established with other clients. We represent that other data as “USERS SENS-ITIVE DATA!”.
- The server then sends exactly the 5 byte message response which exactly corresponds to “HELLO” in server’s memory. The server does not leak any sensitive data from its memory.
In the corrupt scenario, the client is an attacker who sends the same Heartbeat message over the TLS channel except now the attacker sends the incorrect size of the message content.
The figure above illustrates a corrupt “Heartbeat” message flow where the attacker sends an incorrect size with the “HELLO” message content.
In this example, here are the three steps in the TLS channel work:
- The client sends a message with size 25 of bytes but the content of the message really only contains 5 bytes (“HELLO”).
- The server receives the message content “HELLO” and stores it in its memory so it can send it back as a “Heartbeat” response. Just like before, there is other data stored in the server memory from other different TLS channels.
- The server then sends a 25 byte message response which exactly corresponds to number of characters in “HELLO” plus “USERS SENS-ITIVE DATA!” in server’s memory.
When the server looks at the size of the response message it’s suppose to send back, it does not bother to check to see if the original message content was the correct size. Because of this, the server leaks sensitive data from its memory as part of the response message.
How do you stop Heartbleed from happening?
Instead of relying on individual web servers, application servers, ESBs, and other IT components to provide SSL-based protection with their own varying OpenSSL versions, corporations should deploy a centralized security gateway that is custom-built for handling SSL traffic. Forum Sentry gateway implementation of SSL/TLS is not susceptible to Heartbleed security flaw for many reasons:
- Forum Sentry does not use the OpenSSL library for its SSL and TLS implementation.
- Forum Sentry’s SSL/TLS engine has tight memory bounds checking to ensure that an incorrectly supplied size will not result in extra data being leaked from memory.
- Forum Sentry’s hardware devices use Hardware Security Module (HSM) which secures the keys and performs the cryptographic processing in separate memory space.
Benefits of a robust security Architecture via API Gateway
Using an API Security Gateway — such as Forum Sentry — provides a central location for security policy management. Unlike other API gateways, Forum Sentry has been engineered from the ground up with security as the primary focus.
The decision not to use OpenSSL for Forum Sentry’s core was a clear and conscious engineering decision grounded in the fundamental understanding of buffer-overflow exploits, bounds-checking, and strongly typed code. Customers using Forum Sentry are not vulnerable to Heartbleed, unlike those that use gateways cobbled together with OpenSSL.
Regardless of the vendor used for centralizing API security functions, one architectural choice remains clear: through centralizing security, an organization can rapidly patch security vulnerabilities without having to touch a farm of perhaps hundreds of web servers, application servers, ESBs or any other IT components using OpenSSL. Consider the recommended minimum remediation steps for each component:
- Upgrade your OpenSSL libraries
- Generate a new public-private key pair
- Issue a CSR to your CA
- Install the new X.509 in your servers
- Issue advisories to all of your users, customers, and trading partners
- Have all of your users change their passwords
Now consider that you have to repeat these steps across all your application infrastructure components. The time and cost of implementing these steps can be staggering. Also, when IT components go off-line for remediation, the ensuing business disruption can have direct impact on an organization’s top line.
If you happened to have selected an API gateway other that Forum Sentry, you will need to patch your gateway since most rely on OpenSSL. However, even in that scenario, given a centralized security model, only your API gateways would have to be patched rather than all your IT components using OpenSSL. Your best option is to deploy Forum Sentry as a reverse-proxy. This ensures that you are betting on a product built with security as the primary engineering tenant.