Heartbleed is one of the worst security vulnerabilities in recent memory for organizations trusting OpenSSL to protect their data. Learn how this vulnerability can affect your business and how to defend against it.
Heartbleed is a serious vulnerability in a popular version of SSL—the technology that security professionals rely on to protect the most critical data exposed on the Internet. We have pulled together a collection of information to help you better understand the vulnerability and your options for mitigating it.
Existing F5 customers can go here to double-check the health of their F5 devices. If have further questions or if you are new to F5, we invite you to contact F5 to learn more about how you can protect your business from current and future threats.
Watch a moderated discussion with F5 security experts. Recorded April 17, 2014.
List of Questions
An animated exploration of OpenSSL Heartbleed.
The Last Watchdog speaks with F5’s Preston Hogue.
Learn more about how Heartbleed works and your mitigation options.
“There are a variety of points within the data path where solutions could be put into place to mitigate this (and similar) vulnerabilities. Thus customers must choose the most strategic point in the network at which to deploy their selected mitigation.”
Read the Blog
Learn more about the scope of the Heartbleed vulnerability and the role of an F5 ADC in defending against exploitation before and after discovery. The good news: The vast majority of sites using BIG-IP Local Traffic Manager (LTM) to terminate SSL for their applications are not only protected against Heartbleed today, they have been protected all along.
iRules give you complete programmatic access to traffic on your network, providing a powerful, fast mitigation path for new vulnerabilities like Heartbleed. Organizations that don't use conventional SSL termination can still use BIG-IP to mitigation their servers' vulnerability from either the client or server side through an iRule.
SSL Heartbleed Client-Side iRule
SSL Heartbleed Server-Side iRule
F5’s iRules critical to fight against Heartbleed.
Heartbleed is a vulnerability in the OpenSSL cryptographic software library (versions 1.0.1 through 1.0.1f are vulnerable) that allows an attacker to steal information from SSL-protected sites. This vulnerability allows anyone to read the memory of systems that are protected by certain versions of OpenSSL. A user can send a valid "heartbeat" message to the secure server requesting encryption keys, and the vulnerable server will respond with the keys. The reason the vulnerability is called "Heartbleed" is that it "bleeds" sensitive information from the server based on a valid "Heartbeat" message.
Secure servers use secret keys to encrypt sensitive information. This sensitive information could include things like usernames, passwords, emails, bank account information, etc. Heartbleed potentially allows an attacker to steal the keys, the passwords and, well, everything. The Heartbleed vulnerability has been widespread throughout the Internet, affecting nearly a half-million websites, and countless devices from browsers to embedded servers. Pretty big deal...
The good news is that customers who have been using F5 to terminate TLS in front of their HTTPS servers have been protected for the last two years. There are a few corner cases that may require remediation – read on.
The iRule is written for any traffic coming through any virtual server for SSL, so it will protect any protocol that uses SSL as its transport. Therefore, it works for more than just https; it also works for other protocols like SMTP over SSL, FTP over SSL, etc.
That is correct. The BIG-IP does not advertise heartbeat support, so even if a client sends a heartbeat request the BIG-IP will simply ignore it.
One small caveat... if you are running BIG-IP version 11.5.0 or 11.5.1 AND you are using the COMPAT cipher stack, you would be vulnerable to Heartbleed. If you are running any other version of BIG-IP, you are not vulnerable. Likewise, if you are not using the COMPAT cipher stack, you are not vulnerable. So, this situation only applies to a very, very small number of users. The COMPAT cipher stack is not the default, so in order to use this you would have to administratively force a change in your BIG-IP to this stack. Also, we have a Hotfix already released for the 11.5.0 and 11.5.1 users who might have been using the COMPAT cipher stack.
Not a dumb question at all! If you are decrypting and re-encrypting HTTPS traffic, you are safe. Even if the back-end server is vulnerable to Heartbleed, the BIG-IP would not allow the vulnerability to be exploited on the back-end server when the re-encryption happens.
Yes, several websites allow you to check the status of your Heartbleed vulnerability. We don’t officially endorse any of the websites, but Qualys SSL Labs has a good test you can use. Simply enter the domain name to be tested and submit. You will see your vulnerability status in the test results. You can also use the nmap tool with the Heartbleed script to scan an entire network quickly.
For nearly all applications, servers and clients, the F5 NATIVE SSL code stack is the correct choice. However there are a few, rare corner cases where a “picky” client will insist on a protocol behavior that is specific to the OpenSSL library. Any virtual server using a COMPAT cipher should be patched immediately and the certificate associated with the virtual server rekeyed before the service is brought back online. See solution 15159 for more details on upgrading.
Customers passing SSL through the BIG-IP to vulnerable servers (HTTPS or otherwise) can protect them by putting in place a virtual patch based on one of two iRules. The client-side Heartbleed iRule discards all TLS Heartbleed requests in a connection. The server-side iRule is very similar to the client iRule, except it watches the server responses searching for a heartbeat. If it sees one that is longer than 128 bytes, it rejects the connection.
Mitigating incoming Heartbleed is probably more secure for more architectures for the following reason: keeping it out of the network is a firewall-like perimeter security function. See this longer article for more information.
F5 has measured a performance degradation of approximate 10-15% on the server-side iRule. There is likely negligible performance impact for the client-side Heartbleed iRule unless the client is sending large posts.
The "reverse Heartbleed" scenario can occur when a vulnerable client (such as web browser or mobile application) is connecting to a malicious TLS server. That server can then send Heartbleed probes back to the client, potentially compromising it. F5 can protect internal clients by terminating TLS with its TLS inspection abilities before proxying their connections to the internet. See the Secure Web Gateway solution for outbound web security.
Specifically, F5 can offer assurance that it uses code quality tools such as static code analysis and fuzz testers. F5 also practices security development lifecycle (SDLC) processes such threat model assessments and peer code reviews.
In general the only way to evaluate the security posture of a company is to look at their response to previous security incidents. Did the company Do the Right Thing? Does it have a documented security incident response process for its customers, and does it follow that process? F5 stands behind its open response history and engagement within the security community. F5 continues to invite all security professionals who have found security issues with F5 equipment or services to bring them to us so that we can fix them and alert our customers and partners.
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.