AWS Networking: SSL/TLS with Load Balancers

I came across this question whilst preparing for the Advanced Networking exam:

A company wants a highly available web server that will sit behind an Elastic Load Balancer. The load balancer will route requests to multiple target groups based on the URL in the request. All traffic must use HTTPS. TLS processing must be offloaded to the load balancer. The web server must know the user’s IP address so that the company can keep accurate logs for security purposes.

The options involved choosing between an Application or Network Load Balancer and using a HTTPS or TLS listener and got me thinking about how TLS actually works and what it means to 'offload' the process to the load balancer.

What is SSL/TLS?

TLS is a protocol that encrypts data in transit between client and server.
It is the successor to SSL and provides a more advanced and secure protocol that provides encrypted communication over a network. TLS uses more robust hashing algorithms like SHA 256, a more efficient handshake process for establishing secure sessions and better data integrity to ensure data is not altered during transmission.

If SSL is deprecated and only TLS is used why do people still commonly refer to it as SSL or SSL/TLS is the question that was on my mind and here's what Chat said:

Excellent catch 👌 — this confuses almost everyone at first.
The short answer: TLS replaced SSL, but the name “SSL” stuck around in industry and tooling.
SSL is the old protocol (SSLv2, SSLv3) → insecure and deprecated. TLS is the modern replacement (TLS 1.2 / 1.3) → what we actually use today.
People still say “SSL/TLS” because:

• Historical habit (TLS was once called “SSL 3.1”).
• Vendors still market “SSL certificates” (really TLS certs).
• Config files use old names (ssl_certificate in nginx, ACM “SSL cert”).
• SSL became a generic term for encrypted web traffic.

The SSL/TLS Handshake Process

The SSL/TLS handshake is a process that establishes a secure connection between a client and a server. Here’s a simplified overview of the steps involved:

1. Client Hello: The client sends a “ClientHello” message to the server to establish a connection, proposing the supported SSL/TLS versions, cipher suites and a random number for session key generation known as the "client random."
2. Server Hello: The server responds with a “ServerHello” message, selecting the SSL/TLS parameters, the server's SSL certificate and the "server random."
3. Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it to confirm that the server is who it says it is.
4. Client Key Exchange: The client generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server. Session Keys Generation: Both the client and server generate session keys using the pre-master secret.
5. Finished: Both parties exchange encrypted messages to confirm that the handshake is complete.

How does this work with Load Balancers and Offloading?

Offloading to the load balancer means that traffic is decrypted by the load balancer before it is forwarded to the target servers through a process known as SSL termination.

When a client connects over HTTPS, the load balancer performs the TLS handshake, validates the certificate, and establishes the encrypted connection. Once the connection is secure, the load balancer decrypts the incoming traffic and forwards it to the backend servers in plain HTTP. For high performance applications, decrypting SSL/TLS traffic at the load balancer can optimise performance and simplify SSL/TLS management. SSL termination helps speed up the decryption process and reduces the processing burden on backend servers.

Application Load Balancer (ALB):

Supports HTTPS listeners, TLS termination, and automatically injects the X-Forwarded-For header so backend servers can still log the real client IP.

Network Load Balancer (NLB):

Can also terminate TLS, but operates at Layer 4. If end-to-end encryption is required, NLB can forward encrypted traffic to backend servers (TLS passthrough) or terminate TLS at NLB (similar to ALB, but without HTTP header features). If mutual TLS (mTLS) is required, NLBs can support this to allow the load balancer and backend servers to authenticate each other.

Benefits:

Performance Optimisation:

TLS handshakes and encryption are computationally expensive. By shifting this work to the load balancer, backend servers no longer need to handle decryption, freeing up CPU and memory resources for application logic.

Centralised Certificate Management:

Instead of managing certificates across multiple servers, you only need to maintain them on the load balancer using AWS Certificate Manager (ACM), which can automatically renew and rotate certificates without downtime.

Scalability:

Termination at the load balancer makes it easier to scale backend servers in and out since each new instance doesn’t need its own TLS configuration. The load balancer ensures a consistent secure entry point.