It's a fair question, right? Let's take away the strain of SSL terminations from our application servers and let the load balancers deal with it. After all, why would we want to bog down our nifty application with network-level considerations? Largely this is something I agree with but, with some workloads, the truth is this just doesn't make sense.
When might you consider terminating SSL connections at the load balancer?
Let's start by looking at a few reasons to terminate SSL connections at the load balancer. I'm sure you can think of more - so please feel free to throw your views in the comments!
- Optimized SSL termination - Often load balancers are just simply better at doing this job, using smart software that takes advantage of the co-processing features of CPUs to remove intensive computational work, or by relying on specific hardware to do this (e.g. ASIC and FPGA cards).
- Advanced routing - Another awesome feature of load balancers is the ability to route traffic to different backend servers based on the content of the data packet. It goes without saying that if the data is encrypted we can’t see or understand what the data is. So we need to decrypt it first, read the contents, make a decision about where to send it, and optionally encrypt it again before we post it off to the intelligently selected backend server.
- Security - We all know that SSL certificates expire (it's part of the design). So having all of our servers behind a single entry point means that when they do expire we only have to update the certificate on the load balancer and not all the servers behind. Imagine replacing the certificates on hundreds of servers. That could take ages!
But what if the data is nonsense?
All of these things are invaluable in certain environments. E-commerce is a great example. We may have lots of web servers, some handling the login functions, others responsible for order processing, and maybe even more tracking deliveries. These separate services within the e-commerce platform may not all be running from a single cluster of web servers, they might be distributed across different virtual, physical, and possibly even geographically separate data centers. But we can mask the whole thing behind one steady public IP address, and one branded domain name like www.myshop.com.
So it makes complete sense that we would want to unwrap, read the contents, route a customer to the correct data center or web cluster, and streamline the customer's experience, while also accelerating the platform's performance and resilience.
But what if the data is nonsense? By nonsense, I mean not human-readable. What if we can’t collect any useful information from the data and we don't need to intelligently route. Should we still SSL offload? Well, the answer to this is complicated...
Let's take object storage as an example
Here we generally know that we have a limited number of backend servers typically called “nodes”. Let's bring security in here and say this object storage platform is in a bank. So we want SSL and, as it's a bank, obviously all traffic needs to be end-to-end encrypted.
Let's tackle the end-to-end piece first. Ahhh, hang on. If we are putting a load balancer in the path then we must make sure we re-encrypt the traffic from the load balancer to the nodes. Otherwise, it's not end-to-end encryption. But, if we want end-to-end encryption why are we decrypting at the load balancer in the first place?? Why not just pass it through? Which one of the reasons above warrants this design?
- Optimized SSL termination? Well, this doesn't change, the load balancer is still a superstar SSL machine, but we need to encrypt to the backend servers to achieve end-to-end. So we haven't removed any load from the nodes. They are still going to need to decrypt the traffic. So there is no reason to offload for this benefit.
- Advanced routing? The traffic flowing through the load balancer is raw binary blobs. Most definitely not human-readable. We can't make any really useful decisions here based on the data in the packet. And, ultimately, we are generally going to be sending all data to the same set of backed storage nodes. So there is no reason to offload for this benefit.
- Security? In this scenario we still have certificates on every node, so we still have the same workload to replace them when they expire. We could of course choose not to encrypt to the backend servers if we are sure the network is secure. But this flies in the face of the whole zero trust model. So again, there is no reason to offload for this benefit.
There is one more reason I can think of. In my mind, there is a very clear relationship between the storage demand and the SSL terminations. As the demand for storage scales up, typically more nodes will be added. More nodes means more CPU and RAM, which also means more power to terminate SSL connections. So if you terminate SSL connections at the load balancer rather than the nodes, you may find that you don't just have to buy more storage nodes when you scale up, you also need to buy a bigger, more powerful, load balancer!
So it's clear to me there are workloads that absolutely benefit from SSL offload, and others that don't. The load balancer is a swiss army knife that requires the right features to be used for the right workloads. For example, with object storage, you would absolutely use it for resilience and application acceleration, but there is a better alternative for SSL terminations.
The long and short of it
I guess I'm challenging you to fight the instinct to use the shiny superstar load balancer for everything “because you can”. Take time to architect your topology - or ask us! While load balancers are hands down the best tool for terminating SSL connections, it doesn't mean they are always the right tool for the job.