Blog

5 Questions to Ask your Load Balancer Vendor

By | Date posted: April 22, 2014
Heartbleed

Heartbleed, the recent security flaw found in OpenSSL, is just one of many flaws discovered in this open source code base. Many load balancer providers have bolted on OpenSSL to manage SSL traffic through their product. Here are five questions you should ask to ensure you are not at risk for more OpenSSL flaws:


1. Do you use OpenSSL in your products?

As more and more flaws are found in OpenSSL, there comes a point when you have to ask yourself if it’s worth it? Heartbleed, the most recent security flaw has been publicly unknown for 2 years. Are there other flaws that we don’t know about that are currently being exploited? There are other ways to secure your SSL traffic. Security can no longer be an afterthought.

2. If yes, were you aware of the potential security risks that come with OpenSSL?

The fact that OpenSSL is being used in a product designed to process secure traffic should raise a red flag. It tells you that security is not the company’s first priority. You would be better off utilizing an SSL Proxy for SSL processing along with a load balancer for traffic management.

3. Do your engineers review the code changes that are checked into the OpenSSL library?

Code review is performed by professional engineering teams as a general best practice. Having an engineering team review every line of code before it is deployed should be an expected best practice in any reliable technology company. It will help reduce security flaws, downtime and other potential risks. When working with something as critical as SSL traffic, it is imperative that all code be reviewed to avoid bugs like Heartbleed.

4. What programming language are your load balancers written in?

This is often overlooked by many. Some programming languages are more secure than others. Did you know that if OpenSSL had been written in Java, Heartbleed could have been prevented? C, the programming language that OpenSSL was written in, has no protection against buffer overflows, which is essentially how Heartbleed has the potential to leak additional information.

5. What is your plan to replace OpenSSL in your products?

If your load balancer provider doesn’t have a plan to remove OpenSSL from their products, it’s time to consider another vendor for managing your SSL traffic. OpenSSL “only has one full-time developer and generates less than $2,000 in donations a year”. Are you willing to trust your IT infrastructure on code base with such little funding and development resources?

Related content:

2 Comments to "5 Questions to Ask your Load Balancer Vendor"

  1. Reply
    Malcolm Turnbull
    May 12, 2014 at 9:57 am

    As the founder of Loadbalancer.org I thought I might as well answer here:

    1.Yes. (and it was only the UDP bit that was known about for 2 years and no one cares about that.)
    2. Totally disagree, OpenSSL is widely used precisely because it is so secure – admittedly Heartbleed was a MONUMENTAL cock up.
    3. None of our engineers would understand the code well enough to check – hows that for honesty?
    4. C – Linux Kernel based LVS + HAProxy + Stunnel + OpenSSL
    5. No intention whatsoever.
    The open source system is the best form of defence against security issues, more eyeballs = more security. Most bugs/security issues these days are client side hacks like the BEAST attack (http://blog.loadbalancer.org/ssl-termination-the-beast/).

    But yes fully agree Heartbleed was a nightmare for a lot of customers. Our most recent load balancers prior to v7.6 were all vulnerable to the heartbleed attack if they were used for SSL termination and our heartbleed patches are here: http://blog.loadbalancer.org/loadbalancer-org-releases-patch-for-the-openssl-heartbleed-vulnerability-cve-2014-0160/

  2. Reply
    rdrunnerxx
    August 4, 2014 at 7:09 pm

    As a developer I would try not to use open source in a “commercial” product. But if I decide to do so, under extreme circumstances, then I would want my team to understand it and be able to maintain it (for the right salary, there are gurus out there who can read/own anyone’s code).

    But it is not about that. It is about what you do as a vendor once a flaw is found in your product. To me, it is no brainer. You fix it and put the patch on your site for everyone to download free of charge. But unfortunately, that is not what is happening with some of these vendors. Their price model is based on support. Even a hardware firmware patch is considered to be a support issue. I find this to be appalling.

Leave a Comment