Heartbleed is likely one of the worst security vulnerabilities of all time. Worse, the versions of the popular OpenSSL library that make Heartbleed possible have been widely available for more than two years, meaning that the vulnerability has spread widely throughout the Internet.

Worse still, for those last two years, any attackers aware of Heartbleed’s existence could have used simple, untraceable messages to retrieve memory values from vulnerable servers.

 

Figure 1: A Heartbleed probe


Figure 1: A Heartbleed probe

 

Compromised assets could have included SSL private keys, user passwords, and other highly sensitive information. See here and here and here for more technical analysis of the vulnerability itself.

Put simply, Heartbleed is very close to a worst-case scenario.

The good news

 

heartbleed mitigation

The good news from F5 Networks is that if an F5 BIG-IP Application Delivery Controller (ADC) has been delivering your HTTPS application for the last two years, that application was not vulnerable to Heartbleed.* There’s still work that needs to be done on behalf of F5 customers and others, but we’re beginning the transition to the post-Heartbleed world—including immediate countermeasures and next steps.

 

Internet Impact Analysis

After the Heartbleed vulnerability was announced, Netcraft performed an analysis based on key parameters of the threat surface. Their analysis suggests that the exposure to Heartbleed today is around 15 percent of all SSL sites. That is over a half million private keys.

Of course, different SSL keys have different levels of protection based on their values. The security of an online banking site’s private key is more significant than, say, that of a news aggregator’s private key. Root certificate authority keys are the most prized in the world.

So who is vulnerable?

The initial Heartbleed announcement indicated which sites are likely safe and which are not.

 

"Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software. Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most."
–Heartbleed researchers

 

It’s pretty simple to figure out which sites will likely be the most vulnerable: those using recent versions of open-source software servers (such as Apache and NGINX). Those sites and most others can be grouped into the following risk categories based on the information in the Heartbleed announcement, the Netcraft analysis, and F5’s engagement with hundreds of SSL customers.

 

Group Likely Heartbleed Risk Why?
Financial Lower Use of FIPS 140-2 crypto-HSMs
Defense Lower Use of FIPS 140-2 crypto-HSMs
SLED Medium Lots of older, non-Linux systems
eCommerce Medium See F5 status below
Web 2.0 High Likely to use affected OpenSSL libraries
Cloud High Most likely to use affected OpenSSL libraries

Figure 2: SSL site verticals generally at risk

 

F5 ADCs are a Heartbleed countermeasure

Let’s get to the good news. There are three ways that F5 BIG-IP devices or software can be used as a countermeasure for Heartbleed.

First: Normal SSL profiles already protect against Heartbleed

The first defense is via the native SSL termination ability of the BIG-IP platform’s SSL profiles. The vast majority of sites using BIG-IP Local Traffic Manager (LTM) to terminate SSL for their applications are already protected against Heartbleed. This is because the primary SSL engine within the F5 traffic management microkernel is our own highly optimized and hand-written code. Therefore, when the F5 platform is terminating SSL on behalf of a pool of servers, it is already providing the necessary protection to applications. These applications are what the Heartbleed researchers meant when they referred to “fortunate consumer sites” that were spared vulnerability—those whose businesses depend on application uptime and who have invested in SSL termination equipment (read: SSL-terminating load balancers) for capacity and provisioning.

 

Figure 3: How BIG-IP LTM protects against Heartbleed

Figure 3: How BIG-IP LTM protects against Heartbleed

 

Second: Hardware security modules provide cryptographic boundaries

The SSL keys that are likely safest are the high-value keys of the financial industry, the defense industry, and the certificate authorities. These organizations often keep their keys within a FIPS-140 Level 3 cryptographic boundary called a hardware security module (HSM) that keeps the keys safe from memory-cracking tools. Many such organizations use ADCs with an integrated HSM.

 

Figure 4: Network HSM architecture

Figure 4: Network HSM architecture

 

Interestingly, there’s a whole new network HSM architecture where SSL keys are stored within FIPS 140 cryptographic stores under centralized management. The ADC asks these devices to decrypt SSL session keys, but then performs the remainder of the SSL session cryptography themselves.

Third: F5 iRules protect the rest

An F5 ADC has something that no other ADC has: a fully programmable, data-plane scripting language. Called iRules, it is supported by the F5 DevCentral development community made up of over 100,000 active users.

For organizations that cannot use either of the two more conventional solutions for SSL termination described above, the third option is to use iRules to provide mitigation—without decrypting the SSL connections themselves.

Scenarios where a defense based on iRules might make sense include:

  • A pool of servers with a security policy restricting private keys to origin server hosts.
  • An ingress point for multi-tenant SSL sites (using SNI and different keys).
  • A virtual ADC fronting a pool of virtualized SSL sites.

For these cases, F5 wrote two iRules to mitigate the Heartbleed vulnerability. The problem space is a fascinating mix of false-positive avoidance, performance assurance, and security, which must all be balanced within a single rule that cannot inspect the plaintext.

The first iRule stops any attempt by a client to send a heartbeat request. Since very few legitimate clients send heartbeats, this iRule will stop any malicious clients and prevent the attack from reaching your servers behind BIG-IP.

A second iRule blocks the server from sending any large heartbeat responses that may contain portions of your server’s memory.

If neither of these iRules suffice, an organization can develop its own. It happens every day. That’s the power of iRules and the DevCentral community.

What about the cloud?

The savvy reader may have realized that cloud computing has its own Heartbleed threat profile. This is true, with the intensity of the threat varying by the specific cloud deployment situation.

 

A typical LAMP cloud site: A typical cloud site contains instances of a Linux distribution running Apache, MySQL, and PhP (a combination commonly known as LAMP). Given that cloud adoption is a relatively recent phenomenon that overlaps with the introduction of the Heartbleed vulnerability two years ago, these cloud LAMP sites incur the highest risk.

A cloud with F5 ADC hardware: Many F5 customers use our hardware platform to front their cloud instances. They achieve significantly higher densities with an F5 ADC merging TCP connections, caching common objects, and, of course, offloading expensive hardware cryptographic operations. Where F5 is terminating the SSL, those customers are already protected. If you’re one of them, you should simply make sure that none of the virtual servers are passing HTTPS without decrypting it first. (See below).

An F5 virtual ADC: In fully virtualized clouds, even the F5 modules are virtual instances. Without the underlying cryptographic hardware offload taking place, there may be less incentive to have the F5 module terminate the SSL for HTTPS servers. The Heartbleed risk is therefore higher than with the hardware deployment in the previous case. The F5 platform can still provide protection, however, because the software implementation of the virtual ADC’s native SSL stack is also not vulnerable to Heartbleed and therefore provides a defense.

Next Steps

Existing F5 customers can basically read a single solution to double-check the health of their F5 devices and sleep tight knowing that not only are they safe now, but their applications have been resistant to Heartbleed for the last two years. If you need help, click Contact F5 to be connected to your F5 account representative.

If you are new to F5, we invite you to contact F5 to learn how you can protect your business from current and future threats.

Contact F5

 

Conclusion

American computer scientist Gerald Weinberg once said, "If builders built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilization."

Heartbleed is one of those woodpeckers.

The good news is that the F5 BIG-IP devices and virtual instances already spread throughout the Internet can defend the HTTPS applications they serve. Administrators can verify that defense and then work with their security teams to upgrade systems at their own pace. And those without protection can get it with a simple call to F5 or an F5 trial edition.

 

 

*If you are doing SSL termination on the LTM, you are protected unless you have moved off the secure F5 SSL stack by changing the default ciphers to COMPAT on 11.5.0 or 11.5.1. We have determined this impacts a very small portion of F5 customers.

If you are using 11.5.0 or 11.5.1 and exposed your management interface to the Internet, you are vulnerable. OpenSSL 1.0.1 is used for the BIG-IP Management interface. F5 does not recommend this configuration.

Questions about OpenSSL Heartbleed? Ask the F5 Community

 

 

F5 Networks has validated that all of its customer-accessible websites are safe from the OpenSSL vulnerability known as Heartbleed. Visitors who access and/or log on to any F5 web property should have complete confidence that their online activity is safe and secure.

While no specific action is necessary, F5 takes this opportunity to recommend that all users follow generally accepted best practices for resetting passwords regularly.