How to Solve Encryption Compatibility Problems
Encryption has many IT managers in a bind. The massive move of applications to the cloud has created a strong reliance on the Secure Sockets Layer/Transport Layer Security protocol and digital certificate infrastructure to secure traffic over the open Internet and maintain confidentiality of data.
But SSL/TLS has recently been subject to some serious security vulnerabilities with a bevy of interesting names, such as FREAK and POODLE. Some of the problems are specific to older versions of the protocol (SSLv.3.0 and TLSv.1.0); some are caused by typical older configurations, such as poorly chosen encryption and signature algorithms; and some are actual bugs within the most popular implementations, such as OpenSSL.
Avoiding Compatibility Problems
These discoveries have led to a rush to patch SSL/TLS libraries and to change the way that the protocol is used. And that’s where the complication comes in. Normally, IT managers evaluate security patches and upgrades based on risk, and they can choose to push off disruptive or expensive changes if they believe the risk doesn’t warrant the cost. But SSL/TLS is a client-server protocol, and IT managers don’t necessarily control all the variables.
Web browser authors and public Certification Authorities are releasing products that aren’t backward-compatible with older SSL/TLS configurations. This forces application owners to patch their systems or risk having the application fail to work on current browsers and operating systems.
Patching is always a good idea, but sometimes it can be expensive or impractical. Production timelines may not permit quick patching schedules. And some third-party software makers don’t release updates in a timely way. SSL/TLS offers IT managers solutions to their compatibility problems without patching legacy apps.
Load Balancers to the Rescue
Sometimes known as application delivery controllers, load balancers are a staple in most networks. Placed in front of web servers, a load balancer can handle the SSL/TLS encryption to the user’s web browser.
The load balancer moves the SSL/TLS conversation from a complicated application server farm to a simpler device where SSL/TLS configurations are easily updated and where patching is not a major disruptive event. If the load balancer’s SSL/TLS implementation and configuration are current, the application continues to run securely.
Using load balancers in this way brings other benefits. Moving the SSL/TLS encryption to a dedicated appliance can speed strained application servers. With SSL/TLS encryption centralized to a small number of devices, the job of maintaining digital certificates and keeping up-to-date encryption configurations becomes much simpler.
Network intrusion prevention also becomes much easier when the traffic between the load balancer and the application server isn’t encrypted. Commercial load balancers support high-availability and clustering configurations, application rewriting to speed performance and, of course, load balancing.
Load balancers and application delivery controllers aren’t the only option for SSL/TLS offload. For those IT managers with truly thin budgets, a simple open-source reverse web proxy on a dedicated server can perform this function.
Unfortunately, performing SSL/TLS offload on web server traffic may not solve all compatibility problems. A growing number of application programming interfaces for web services, such as Simple Object Access Protocol and Representational State Transfer, also use SSL/TLS for intersystem communication. In these cases, adding an intermediate device can cause performance problems between systems.
