0

I have read, namely on Rackspace, that one should not use SSL termination for sensitive information (search the page for "SSL Termination should not be used"). Firstly, why would that be the case. Secondly, what in the world is the value of having SSL, if you can't trust that the data is securely transported?

My guess on the first question is that somebody could just add an X-Forwarded-For header with an HTTPS URL, if they knew the direct IP of the server, bypassing the load balancer entirely, and coming in on port 80. I could overcome that via iptables (only allow port 80 from the load balancer), right?

Notes: My servers are in the same private network as the load balancer (regarding the "What are the security concerns?" note in that Rackspace article).

Improve this question
2
  • The private network could be made secure by other means: serverfault.com/questions/33195/… Commented Mar 29, 2015 at 19:01
  • @Raedwald interesting, thanks. I ended up leaving Rackspace for Heroku. Rackspace, in my opinion, has too many half-baked tools, or at least they did when I asked this question. Commented Mar 29, 2015 at 19:03

2 Answers 2

Reset to default
3

What they're telling you is that if you choose to have the SSL end point on your end be in the load balancer (rather than a server that the load balancer routes to) then you should be aware that regardless of how safe the data was on the way to the load balancer than once it leaves the load balancer it is in the clear. In a private data center it is not uncommon to have SSL processing offloaded to load balancers or specialized hardware and then have the inner pipe (the one that was formerly wrapped in SSL) continue off to regular webservers for servicing.

The warning they give is that if your cloud servers are not in the same datacenter as your load balancer that if you unwrap the ssl session in the load balancer the traffic from their to the webservers will be transparent and routed across the public network.

As for your speculation on the X-forwarded-for stuff, you misunderstood what they meant. They are saying that if your web-service wants to ensure that clients are using SSL but you are stripping off the SSL wrapper at the load balancer that they can have the load balancer stick an extra header for your webserver so that you know that the client DID use SSL even though your webserver will say that no SSL is in use.

hope that helps you out

Improve this answer
4
  • My speculation wasn't about that. I understand that bit completely. My speculation is that the reason they recommend not using SSL termination for sensitive data is that your web server has no idea whether the X-Forwarded-For is from the load balancer or from some shady client who simply modified their headers. My question is, therefore, given second case isn't a problem (due to my iptables not allowing any traffic from anywhere but the load balancer), and that my servers are in the same private network, are there other concerns that remain? Commented Jun 5, 2013 at 17:19
  • 1
    The concern is that the private network may be compromised, therefore putting the unencrypted traffic at risk. If you don't own or manage the private network then you can't guarantee it's security. Even if you do own and manage it that's not a risk I'd be willing to take. The closet you can get to guaranteeing that the stream hasn't been "hacked" or tampered with is with end to end SSL. Commented Jun 5, 2013 at 17:32
  • 1
    The header X-Forwarded-Proto: https is typically used for this purpose. Commented Jun 5, 2013 at 17:44
  • Thanks, guys. I appreciate it. I was really hoping to offload SSL to the LB, cause it means reducing my server's CPU utilization by at least 20% in some cases. Commented Jun 5, 2013 at 21:11
1

The rackspace doc you mention is a little unclear, but I believe the intent is this:

You want sensitive information using SSL as much as possible. (all the way from the client to your database)

If you enable SSL termination at the load balancer tier, the security stops there. (sensitive data would be transmitted in plaintext between your loadbalancer tier and your app tier.)

I believe that this is the intent in the documentation. You should avoid any unencrypted transfer of sensitive data.

Yes, you might be in the same 'private network', but your customers will be better served with encrypted traffic end to end.

Best of luck.

Improve this answer
3
  • If I'm transferring the data in a private network, why does it matter? Commented Jun 5, 2013 at 17:15
  • 1
    Do you own the network? Do you own the switches? Who can login to those switches? Is the network physically locked up in a cage? If someone plugged in to that network and tried to snoop your traffic, would you know? If you don't know then you should encrypt your traffic. Commented Jun 5, 2013 at 18:45
  • Ha, fair enough +1 Also, I've read that PCI compliance means encryption from the client to the gateway :( Commented Jun 5, 2013 at 21:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.