I recently got a question from one of our clients about what the best method might be for load balancing multiple servers that run their ASP.Net based content-management system (CMS). Their internal team had suggested using session tracking, rather than IP tracking, of the end-user by inspecting the ASP.Net session variable in the cookie. I said that was fine, and that, in fact, it’s a simple way to handle load balancing by session rather than IP address. While this method, which is known as SSL Offload, might seem to be the obvious solution to most, it is still important to recognize the advantages of using it over simple source-IP address-based load balancing, in which the SSL encryption is handled on the back-end servers while the Load Balancers simply lock all requests from one IP onto a single back-end server:

• SSL Offload handles high session loads from single points, which is common in an organization that performs proxying, or hides their users behind a single IP.
• SSL Offload also handles a different issue, in which a single person might be behind their ISP’s load balancer, where their connection might flip between multiple IPs.

The setup of a simple SSL Offload with a load balancer would look like this:

Reflecting more on the best way to load balance, I considered that, at scale, it might better allow the Load Balancers to inject a session-tracking ID, and re-encrypt the data in freshly encrypted connections back to the webservers. There are a few good reasons why this method is the best choice:

1. While the ASP.Net session IDs are randomly generated, there is a small possibility that one server may generate a session ID that is already in use on another. This would result in an inadvertent session hijack between the two users, or worse, data disclosure or corruption. We definitely don’t want to introduce a security breach to our clients’ websites while implementing architecture to improve functionality.
2. The above scenario could be performed intentionally, as well. While difficult (as the randomization is heavy here), it’s certainly not impossible. For instance, if the session variable isn’t properly randomized, or if someone manages to execute a Cross-Site Scripting Attack (XSS) against another user, anyone could conceivably grab another person’s session ID and start using it themselves.
3. The use of the ASP.Net session variable as a means for tracking the user would reduce the ability to programmatically change the session ID mid-process. For instance, if you want to generate a new session ID to avoid session hijacking after switching from http: to https:, the user might be placed on the wrong back-end server and, therefore, invalidate the session ID change.
4. The implementation itself creates the possibility of a local third party monitoring the traffic with a network tap behind the Load Balancers and gaining access to the decrypted data. If said data contains sensitive information, we don’t want to have it decrypted on the wire.
5. This might actually break the CMS if it’s not implemented properly. For instance, some CMS’s have a “force encryption” option that results in the server checking to ensure that the incoming protocol used is SSL and if not, redirect the user to the encrypted page. In this case, that check function would result in a redirect loop and fail.

The configuration would be similar but would include implementing an additional SSL Certificate on the back-end servers, and would look like this:

Because of these concerns, ITX recommends injecting a fresh session-tracking ID into the cookie at the load balancer itself. Most modern Load Balancers are fully capable of implementing session tracking as described, and we end up providing a much smoother journey for our clients by ensuring that their web experience in the CMS serves them consistently and in a way that provides strong security around their data.

*Note that when referencing SSL in this article, a minimum of TLS 1.1 or 1.2 is recommended, as all of the SSL cryptographic protocols are now discouraged for production servers due to the problems with their implementation.

References:

ASP.Net. https://dotnet.microsoft.com/apps/aspnet

Usha Dadighat. What is SSL Offloading? https://www.techwalla.com/articles/what-is-ssl-offloading

OWASP. Cross-site Scripting (XXS). https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Jonathan Coupal (2015, July 1). Security and Your Brand: The Ultimate Relationship.

Sean Flaherty (2016, Feb 11). Customer Loyalty is Not a Transaction.