0

I'm using NGINX to do sticky session load balancing in front of a node.js app that will support http, ssl, and websockets. If I want the load balancer to simply forward requests to the node.js server and always have the node.js server handle any SSL termination, will it still be possible to use sticky sessions based on cookies or IP address? Or will I need to do SSL termination at the load balancer level?

If I need to do SSL termination at the L.B. level, then do I need to re-encrypt the request before sending the request off to the node.js server?

Justin Meltzer
  • 711
  • 1
  • 9
  • 19

1 Answers1

2

If you want the server to handle SSL termination you could use:

  • the SSL-ID to do the load balancing but is has limitations as metioned here
  • the client IP but have impact ofe.g. large proxies

If you would want to circumvent these problems you can terminate the SSL session on the LB and use cookies for stickyness. Unless some limitation with the application (eg hard-coded links) there is no need to re-encrypt.

Zabuzzman
  • 733
  • 10
  • 25
  • thanks! so the client IP is available without having to decrypt the request? I can simply use the `ip-hash` NGINX directive for this? – Justin Meltzer Apr 27 '13 at 19:03
  • Note that the "client IP" actually means the source IP of the incomming packet. There are network components that will change the source IP: hide-natting firewall , forward proxy, ... It will depend on your setup whether the source IP is still usefull when it arrives at the LB. – Zabuzzman Apr 27 '13 at 20:44
  • Can you be a bit more specific? Will the `ip-hash` directive work for the client IP? Or is it only for HTTP headers? – Justin Meltzer Apr 27 '13 at 20:46
  • It will work. Apparently it uses a hash of the Class-C network address of the client IP, meaning that all hosts in a Class-C network will be directed to the same server. – Zabuzzman Apr 27 '13 at 20:49
  • Cool, thanks. So I'm guessing that in my nginx config instead of an `http {}` block with SSL enabled, I just simply use a `tcp {}` block that proxies based on ip-hash, and let my backend app do the ssl termination? – Justin Meltzer Apr 27 '13 at 20:51
  • That's a good start. You can look into alternatives it turns out this setup wouldn't suffice... – Zabuzzman Apr 27 '13 at 20:55
  • The only viable alternative I really see is to rewrite my back-end app to no longer need session stickiness. With sticky sessions, as you mentioned stickiness based on SSL-id has its drawbacks, and using cookies means I'm transmitting unencrypted traffic through Amazon's network (which is not attractive from a security standpoint). – Justin Meltzer Apr 27 '13 at 21:01
  • You could always re-encrypt on the LB... A single connection does become CPU expensive that way. – Zabuzzman Apr 27 '13 at 22:25
  • Yeah it does. But is there an easy way for NGINX to do this? – Justin Meltzer Apr 28 '13 at 00:17