We all know the internet is taking over every aspect of our lives. Shopping, banking, and communicating are all processes that we do almost every day online. As we move to doing more and more, it becomes that much more important to make sure that all of our interactions are secured and protected. That’s why almost every website these days is using SSL. And while most of us in the IT world know what SSL is and know how to connect using HTTPS, many everyday users don’t have any idea what we are talking about. They take for granted that when they surf to protected websites, there is usually a mechanism for redirecting users from HTTP to SSL. When such resources are behind the Citrix (NetScaler) ADC, there are 3 distinct methods for redirecting this HTTP traffic.
METHOD 1 – Down vServer Method
This is the “down and dirty” method because it is simple to deploy and there are even wizards on the Citrix ADC that help deploy this method. The premise is that, in general, when a Load Balancing vServer goes down, it has a “protection” feature that allows for specifying a Redirect URL. This Redirect URL is typically an “I’m Sorry” page or other type of maintenance message. Instead of working as a fail-safe mechanism, we can build a Load Balancing vServer with the same IP address as the SSL vServer and have it listen on HTTP port 80. By not binding the vServer to any backend services, the vServer is permanently in a down state and therefore can always lean in the Redirect URL property. This allows the vServer to listen for any traffic coming in on HTTP and Port 80 to be redirected to the stated HTTPS URL.
PROS: Easy to deploy
CONS: vServer will be reported as DOWN and generate SNMP alerts for down entities. Load balancing is a heavy-weight back-end feature, so CPU is wasted on features to look at a packet that will ultimately not be processed.
METHOD 2 – New Simplified Method
Starting with NetScaler 11.1, there is a new property to allow for easy redirection from HTTP to SSL for Load Balancing. For Load Balancing of SSL content, a vServer of type SSL using port 443 is creating. Backend services are bound as well as a SSL certificate. The vServer not contains a property for “Redirect from HTTP.” It requires which HTTP port the ADC should be listening on and which URL it should redirect to. This allows the appliance to perform the redirect without the need for an additional vServer.
PROS: Single entity to manager,- eliminates down vServer.
CONS: Not available with all vServer types
METHOD 3 – Responder
Some of the most powerful features on the ADC are features that utilize the policy engine, such as Rewrite and Responder. Using the policy engine, Responder can take the URL from the users HTTP request and reformat it using HTTPS. This can be customized to include only the host name or the host name and URL path.
A Responder Policy then looks to see when users are utilizing the wrong protocol and then invokes the redirect action. This is a very efficient process from the packet processing standpoint. Note that in the expression there is an explanation point. This negates the expression to say we are looking for when the clients SSL connection is NOT using SSL.
Furthermore, traffic can be brought into an HTTP vServer that is in UP state by creating a fake service that doesn’t perform health monitoring. This vServer is used as the bind point for the Responder policy. Therefore any traffic coming in using HTTP is therefore redirected to the corresponding HTTPS URL that was requested.
Once configured, this Redirect policy and the fake service can be reused anytime an HTTP request needs to be redirected to SSL.
PROS: Works for all types of vServer. More control over redirect. More efficient from a packet-processing standpoint.
CONS: More initial steps.
Bonus food for thought:
Citrix ADC 12.1 brings a new way to work with PFX files. In the past, a PFX file needed to be imported and converted to be used. Now, a PFX file can simply be installed and is ready to use with vServers of type SSL.