Support: 1-800-961-4454
Sales Chat
1-800-961-2888

‘Hidden’ https Options For Rackspace Cloud Load Balancers

5

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).

About the Author

This is a post written and contributed by Alexander Scammon.

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.

When he's not busy telling people how to do their jobs and pretending to do his own, you can find him playing around the Bay Area with the fine musical institutions of Frobeck and the Justin Ancheta Band.


More
5 Comments

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.

Thoughts?

Regards,

Ken

avatar Ken on January 21, 2014 | Reply

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.

Cheers,

-Alex

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

avatar alexscammon on January 21, 2014 | Reply

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.

avatar Ken on January 22, 2014

And for those of you wondering how to enable the option via the API, here’s an example of a curl call that will set it:

http://virtualdisaster.net/posts/cloud-load-balancers-the-missing-manual.html#https-only-load-balancers

avatar alexscammon on January 21, 2014 | Reply

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.

avatar Paul Jackson on February 19, 2014 | Reply

Leave a New Comment

(Required)


Racker Powered
©2014 Rackspace, US Inc.