Skip to main content

Command Palette

Search for a command to run...

SSL Termination Explained

How Load Balancers Handle Encryption Efficiently

Published
โ€ข5 min read
SSL Termination Explained

1. Problem Statement

In todayโ€™s applications, almost all traffic is encrypted using HTTPS.

Thatโ€™s great for security โ€” but comes with a cost.

Why encryption is expensive?

Every HTTPS request requires:

  • TLS handshake (CPU intensive)

  • Encryption / decryption

  • Certificate validation

Now imagine:

  • 10,000+ requests per second

  • Each backend server handling TLS

๐Ÿ‘‰ Result:

  • High CPU usage

  • Increased latency

  • Reduced scalability

Real-world problem

Everything looks fine:

  • Servers are UP

  • Load balancer is working

But:

  • Response times increase

  • CPU spikes on backend servers

๐Ÿ‘‰ Root cause: TLS processing overload


2. Concept Explanation

What is SSL/TLS Termination?

SSL Termination means:

๐Ÿ‘‰ Load Balancer handles encryption and decryption instead of backend servers.

Flow:

  • Client sends HTTPS request

  • Load Balancer decrypts it

  • Sends plain HTTP to backend


What is SSL Offloading?

SSL Offloading is the same concept:

๐Ÿ‘‰ Offload TLS work from backend servers to Load Balancer

Think of it like:

  • Load Balancer = Security Gate

  • Backend servers = Workers

๐Ÿ‘‰ Workers focus on business logic, not security processing


Where does decryption happen?

๐Ÿ‘‰ At the Load Balancer

  • TLS handshake happens here

  • Certificates are installed here

  • Traffic becomes plain HTTP after LB


3. Types / Variations

1. SSL Termination (Most Common)

  • HTTPS โ†’ LB

  • HTTP โ†’ Backend

๐Ÿ‘‰ Best for performance


2. SSL Passthrough

  • HTTPS โ†’ LB โ†’ Backend (no decryption)

๐Ÿ‘‰ LB does NOT inspect traffic

Use when:

  • End-to-end encryption required

  • Compliance constraints


3. Re-Encryption (Hybrid)

  • HTTPS โ†’ LB (decrypt)

  • LB โ†’ Backend (encrypt again)

๐Ÿ‘‰ Balance between security + inspection


4. How It Works Internally

Step-by-step flow:

  1. Client sends HTTPS request

  2. TLS handshake happens at Load Balancer

  3. Load Balancer decrypts request

  4. Request forwarded as HTTP to backend

  5. Backend processes request

  6. Response sent back via LB

Optional:

  • LB can re-encrypt response before sending to client

5. Diagram

SSL offload Loadbalancer Diagram

Diagram: SSL-Offload-LB-diagram.png


6. Real-World Example

Consider an e-commerce website during a sale:

  • 50,000 users hitting login page

  • Each request requires HTTPS

Without SSL Termination:

  • All backend servers handle TLS

  • CPU spikes

  • Slow response

With SSL Termination:

  • LB handles TLS

  • Backend receives simple HTTP

  • Faster response

  • Better scalability

๐Ÿ‘‰ Huge performance improvement


7. Common Issues / Pitfalls

1. Backend exposed over HTTP

If internal network is not secure:

๐Ÿ‘‰ Risk of data exposure


2. Certificate mismanagement

  • Expired certificates

  • Incorrect bindings

๐Ÿ‘‰ Leads to HTTPS failures


3. Wrong assumption

โ€œSSL offload = instant performance gainโ€

๐Ÿ‘‰ Not always

  • LB must be sized properly

  • TLS processing shifts load, not removes it


8. Try It Yourself (MANDATORY)

Try it yourself ๐Ÿ‘‡

๐Ÿ‘‰ Click Here: Visualizer


9. Key Takeaways

  • TLS is CPU intensive

  • SSL Termination improves backend performance

  • Load Balancer becomes security + performance layer

  • Choose between:

  • Termination

  • Passthrough

  • Re-encryption

  • Always secure internal traffic if using HTTP


10. Conclusion

SSL Termination is one of the most important optimizations in modern architectures.

It allows:

  • Better performance

  • Simplified backend design

  • Centralized certificate management

๐Ÿ‘‰ Load Balancer is no longer just traffic distributor โ€” it becomes a security gateway.


11. Series Continuity

Previously:

๐Ÿ‘‰ Connection Handling & Timeouts Explained

Next:

๐Ÿ‘‰ Content Switching (How traffic is routed based on URL/path)


12. Final Thought

โ€œEncryption should protect your users โ€” not slow down your systems.โ€

The key is placing it at the right layer.


13. Practical: NetScaler Hands-on

13.1 Mini Lab

  • Create SSL vServer

  • Bind certificate

  • Enable SSL offload

Quick Validation (Mini Test)

After configuration, test from your laptop:

Test HTTPS connection to LB

curl -vk https://10.0.0.10

What to observe:

TLS handshake should succeed Certificate details should be visible Response should come from backend


13.2 Variation / Experiment

Test:

  • HTTPS โ†’ HTTP backend

  • HTTPS โ†’ HTTPS backend

๐Ÿ‘‰ Compare:

  • Response time

  • CPU usage


13.3 Commands (3โ€“5 max)

# Step 1: Add SSL Certificate (Public + Private Key)
# This certificate will be used by the Load Balancer to terminate HTTPS traffic
add ssl certKey myCert -cert server.crt -key server.key


# Step 2: Create an SSL Virtual Server (Frontend Listener)
# Protocol: SSL (HTTPS)
# IP: VIP exposed to clients
# Port: 443 (HTTPS)
add lb vserver lb_ssl_vserver SSL 10.0.0.10 443


# Step 3: Bind SSL Certificate to the Virtual Server
# This allows LB to perform TLS handshake with clients
bind ssl vserver lb_ssl_vserver -certkeyName myCert


# Step 4: Bind Backend Service Group (HTTP servers)
# These are your backend servers receiving decrypted traffic (HTTP)
bind lb vserver lb_ssl_vserver serviceGroup my_sg


# Step 5: Verify SSL Virtual Server Configuration
# Useful to confirm:
# - SSL is enabled
# - Certificate is bound
# - Services are UP
show ssl vserver lb_ssl_vserver