In my work life, I'm involved in the design and architecture of systems and network solutions; I'm also primarily tasked with the implementation of these solutions. In all but rare instances, there's always more than one way to accommodate requirements and choosing the best option becomes the real challenge.
I personally favour options which provide the customer with the most flexibility and control; and it should go without saying that choosing the right tools for the job goes a long way to providing this.
Lots of applications which are Internet facing, or primarily web-based utilize load balancing to distribute load across a farm of servers. This provides fault-tolerance and higher performance. Dedicated hardware load balancers usually perform the role of monitoring the servers in the farm, and distributing incoming requests across them; they can also provide HTTPS and SSL offloading so that the servers in the farm don't have to deal with the processing overhead of generating session keys for encryption. This is a good thing for reasons including but not limited to:
- It allows the server farm to concentrate on serving web requests and not on performing encryption which is processor intensive, increasing overall application performance
- It simplifies SSL configuration for websites by centralizing SSL certificates on the load balancer instead of on every server in the farm
- Wherever security policy allows an HTTPS connection can be terminated on the load balancer, and then sent over HTTP to the server farm, allowing for Intrusion Detection/Prevention systems to inspect the request for malicious content and potentially prevent the server farm from being compromised
- Since the load balancer can see the unencrypted request, it has a greater variety of options available to it to accomplish sticky or persistent style configurations where an application requires that a particular web client or browser is always served by the same server in the farm
Because the load balancer is translating HTTPS requests into HTTP requests, the servers in the farm don't know whether the original client request was HTTP or HTTPS. For applications that are security sensitive, this can be an issue.
Some common workarounds:
- Stop terminating SSL on the load balancer, and instead pass it through to the server farm
- Have the load balancer send a redirect to an HTTPS version of the same URL if the original request was to an HTTP URL
- Have the server send a redirect to an HTTPS version of the same URL if the original request was to an HTTP URL
1) Should be used as a last resort, since it negates all of the aforementioned benefits of offloading SSL.
2) Isn't always possible depending on what type of hardware load balancer is used. It's convenient, but moves control and responsibility away from the customer's application logic to the load balancer. In many hosted customer environments, load balancers are not under direct customer administration.
3) Is marginally more difficult because the server can't tell whether or not the original request was HTTP or HTTPS. This can be fixed easily by having the load balancer insert a custom HTTP header when the request is an HTTPS request, and having the server-side application logic check for the header and send a redirect if it isn't present. It's about 3 lines of code.
Since the decision to have to redirect is based on application-driven security requirements, and the customer is responsible for the application, it would seem to make the most sense to perform and code the redirect logic at the application level.
In the real world, this isn't a common perspective.
