‘Hidden’ https Options For Rackspace Cloud Load Balancers

If you have a site that is served over https only, you might be interested in a “hidden” feature of Rackspace Cloud Load Balancers. You can set up a Cloud Load Balancer to redirect to https in two different ways, but currently only one of them is exposed in the Rackspace Control Panel.

In certain situations (like my own), this “hidden” approach is more secure. In addition, since it’s a single API request to set up, it might save you a whole lot of time and money.

Option 1: http with SSL settings

The first way to set up https with a Cloud Load Balancer is to set up a normal http load balancer and set some settings in the “Optional Features” section. This, quite clearly, is exposed in the Control Panel. There is even a nice Knowledge Center article that describes the steps and the benefits of setting this up.

That same KC article also points out some of the security concerns. Taking the example in the article, if your servers live in a different datacenter from the load balancer, the load balancer will now be sending decrypted traffic to those servers across the public Internet.

Option 2: https… but a problem

So let’s pretend that we want to continue decrypting SSL traffic at the servers themselves. We know that setting up an http load balancer without the “Optional Features” settings won’t work because we ultimately want https traffic. Hitting the load balancer with https at this point simply doesn’t return anything. So we change the load balancer protocol to https and this appears to work at first: it successfully passes https traffic directly back to a server that is expecting https traffic.

But now we have the opposite problem: when someone tries to reach the server with a regular http request they get stuck at the load balancer because it no longer supports the http protocol. Even if you put an http to https redirect on the server, you never reach the server in the first place, so you never get redirected to https.

https with httpsRedirect

Rather than mess around with adding a second load balancer (and paying for it), sharing virtual IPs, X-Forwarded-Proto header and whatever else, you can just set the “hidden” httpsRedirect option for the https load balancer. I call it hidden because it’s not exposed in the Control Panel, but it’s right here in the API docs:

Setting httpsRedirect to true will accept http requests but redirect them to https. Specifically, it appears to return with a “301 Moved Permanently” response, which redirects to the same location, but with https as the protocol.

So, if you happen to want to continue to decrypt SSL at your servers rather than the load balancers, “httpsRedirect: true” is your friend.

In the future

Because I happen to be in the know of such things, the Control Panel team has an enhancement request open to add this setting as an option to an https protocol load balancer. That enhancement hasn’t been scheduled yet, but I’ll update this post when it becomes available (thereby eliminating the need for most of this article… shucks).

For the past 15 or so years, Alex has been gently guiding companies towards better testing and better development practices. What normally begins as an innocent desire to write a few tests usually ends up as a huge, skyscraper-sized robot that automates the testing, deployment and monitoring of all the code everywhere, and also cooks a mean three-egg omelet.


  1. Alexander,

    Great post. It seems like this hidden option could really open up the use of the cloud load balancers to handle traffic that contains personally identifiable information (PII), or other sensitive data.

    The current FAQ (located here http://www.rackspace.com/cloud/load-balancing/faq/ ) recommends against using SSL-terminated cloud load balancers for this type of data…but I didn’t even realize that there was an option to continue SSL encryption/decryption down at the server instance level!

    We’re considering provisioning a dedicated load balancer (an F5 device) into one of our production environments at Rackspace right now because of our application’s heavy use of PII data….but your post seems to open up another possibility.




  2. Hey there Ken,

    Thanks for the comment, glad to know it was useful for someone out there.

    As for your question, it sounds like you’re dealing with PII data already and probably dealing with SSL at the application layer itself. If so, I think this feature would certainly be an option for you.

    I’m sure you’re already chatting to someone here at Rackspace about rigging up the F5. There may be more to your story than I understand, so I would pose the question to them and see what they say. Of course, I’d be more than happy to help talk through the options with you or whomever you’re working with.

    As for the docs that you pointed out, I’ll find out if that thinking should be updated. This is relatively new feature that launched mid-November[1] — it was a happy accident that I stumbled upon the option mere days after it went live.

    Thanks again — let me know if I can be of any help in your discussions.



    [1] http://docs-internal.rackspace.com/loadbalancers/api/v1.0/clb-releasenotes/content/clbv1.19.26.html

    • Awesome, thanks for the response.

      I’ll talk to our Rackspace guys about the possibility of the using the cloud load balancers. At this point we’re pretty far down the path of locking in with the dedicated F5 device, so I’m sure we’ll keep that plan, at least in the short term. It’s certainly desirable (at least for our primary use case) to terminate SSL at the load balancer itself….but I can envision a ton of future possibilities if I can easily get an SSL connection through the load balancer all the way down to the application tier.

      This is pretty awesome stuff.

  3. Thanks for the article. Do we have an ETA of when this will be exposed on the UI? I’m trying to decide whether I want to wait, or schedule dev resources to figure out the API for this.

  4. Is there a way to get the forwarded (real) IP address when using SSL passthru? It doesn’t seem to be provided. Would switching to SSL termination on the LB solve this? Thanks.

    • Lars, unfortunately it is not possible to get the real IP address when using the SSL passthru. Since the LB doesn’t perform the decryption, it cannot modify the headers to add an X-Forwarded-by header to the packet. If it could perform this action, it would be insecure. 🙂
      For traffic that requires being able to read the real IP address (based on headers being passed), it should be served HTTP or not through a load balancer.


Please enter your comment!
Please enter your name here