Loadbalancer redirecting https requests to http

httpsload balancing

Our sys admin has set up a load-balancer that handles all HTTPS requests and proxies them to the server as HTTP. The server doesn't have HTTPS so the connection between LB and server is un-secure but the connection to the LB is.
I'd never seen something like that and I am not really sure it's the proper way to do it.
The actual server is not available publicly, only through the load-balancer.

Is this enough to make it secure? Could one bypass the load-balancer?
Is this a standard technique?

Best Answer

This is typically called 'SSL offloading' and is quite common in bigger setups. It reduces load on the back end servers, since many hardware loadbalancers have special crypto chips which can handle a lot of SSL traffic at high speed. Another benefit is that you have to store the SSL certificate and its private key only in one place, and will only need to replace it there when the certificate it's close to expiring.

One requirement to make it secure is that the nodes which are being loadbalanced aren't reachable any other way. Typically, these nodes are only connected on private IP addresses which aren't routed even within the network, so there's only a layer 2 (ethernet) network between the servers and load balancer, and no other way to connect to servers.

In some cases (for example hosting of PCI compliant setups) this won't be enough, so often SSL re-encryption is used there. In that case the connection between the load balancer and the servers is via SSL as well. The loadbalancer decrypts traffic coming from clients, does its magic (for example pick the right node to proxy traffic to, do some rewriting tricks, etc) and then encrypts it again on the connection to the backend server.

nginx.conf

#lets assume your IP address is 89.89.89.89 and also that you want nginx to listen on port 7000 and your app is running on port 3000

server {
    listen 7000 ssl;
 
    ssl_certificate /path/to/ssl_certificate.cer;
    ssl_certificate_key /path/to/ssl_certificate_key.key;
    ssl_client_certificate /path/to/ssl_client_certificate.cer;

    error_page 497 301 =307 https://89.89.89.89:7000$request_uri;

    location / {
        proxy_pass http://89.89.89.89:3000/;

        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Protocol $scheme;
    }
}

However if a client makes a request via any other method except a GET, that request will be turned into a GET. Thus to preserve the request method that the client came in via; we use error processing redirects as shown in nginx docs on error_page

And thats why we use the 301 =307 redirect.

Using the nginx.conf file shown here, we are able to have http and https listen in on the same port

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

Best Answer

Related Solutions

Nginx – Handling http and https requests using a single port with nginx

nginx.conf

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Related Topic