A coworker was recently helping me with a project when he asked, “Where is the TLS termination happen?” I was immediately confused. I knew the words individually, but I didn’t really understand what he was asking. After some clarification, it started to make sense...but not completely.

To fully understand the answer, I had to go back to the basics. In this post, I’ll walk through how traffic moves across the web, how HTTPS keeps data private, and what’s actually happening during a TLS handshake. From there, I'll get to the bottom of what TLS termination really means.

HTTP

HTTP (Hypertext Transfer Protocol) is the fundamental language of the web. HTTP is a client-server protocol that allows clients to request web pages and other resources, and servers to respond with the data needed to display them. When you visit a website, your browser uses HTTP to send a request to the server hosting the site, and the server returns the data needed to display the page. With HTTP, though, your data is unencrypted. That means that prying eyes can see your data.

HTTPS

HTTPS (Hypertext Transfer Protocol Secure) solves this problem by encrypting the communication between your browser and the server, protecting data from prying eyes as it travels across the internet. The “S” in HTTPS stands for Secure, indicating that the connection is encrypted using SSL/TLS.

But how does HTTPS actually keep data private? That’s where SSL and TLS come in.

SSL vs TLS

Secure Socket Layer (SSL) is a protocol that creates a secure connection between two devices over the internet. Due to vulnerabilities, this protocol is now deprecated.

Transport Layer Security (TLS) was created to fix these issues. TLS is the modern security protocol used to protect data in transit by ensuring privacy, integrity, and authentication for internet communications. A common example is encrypting traffic between a web browser and a web server when loading a website.

Because TLS is essentially an improved and more secure version of SSL, the terms SSL and TLS are often used interchangeably—even though, technically, modern HTTPS connections use TLS, not SSL.

So, how is this data encrypted?

The TLS Handshake

The TLS handshake is like a digital handshake that occurs when you visit a secure site. It's how the browser and server agree on how to encrypt data from prying eyes. Below are the steps of the TLS Handshake.

1. The "Client Hello" - The client sends a hello message with the following information:
   1. TLS Version
   2. Cipher Suites
   3. A string of random bytes called the "client random"
2. The "Server Hello" - The server responds with the following:
   1. It checks for the strongest encryption method they both have in common, and uses that.
   2. A string of random bytes called the "server random"
3. The ID Check - The server sends an SSL/TLS Certificate. You can think of this like a digital passport.
4. The Premaster Secret. The client sends another random string of bytes called the premaster secret. This secret is encrypted with the public key and can only be decrypted with the private key by the server
5. The server decrypts the premaster secret from step 4
6. Secret Key Exchange - Once the browser verifies that the server is legit, a session key is established.
7. Client Finished - The client sends a finished message that is encrypted with the session key
8. Server Finished - The server sends a finished message that is encrypted with the session key
9. Handshake Complete - Handshake is complete, and the communication continues using the session keys. From this point on, every piece of data you send is encrypted.

It’s fascinating to think that all of this happens in just milliseconds, from the moment you type a URL and hit Enter to when the page loads on your screen.

TLS Termination

Ok, here we are. The reason for making this post. TLS Termination. In step 9 of the TLS Handshake, I stated, "Every piece of data you send is encrypted." You might think that encrypted data goes all the way to the application or its database, but that's not necessarily true. TLS Termination is the process of decrypting traffic at a network endpoint, such as a load balancer. This means that after the TLS Handshake is established, encrypted data hits the load balancer, where it is decrypted and sent to the destination server. So from the load balancer to the destination server, it's plain text.

Oh, but wait. Now, unencrypted data is being sent to web apps. "But the traffic is isolated in my company's network". Sure, but what if it's compromised? If an internal network is ever compromised—through misconfiguration, lateral movement, or a breached host—plain-text traffic inside the network can still be exposed. SSL/TLS Bridging and SSL/TLS Passthrough remediate this.

Both approaches help ensure that sensitive data remains encrypted beyond the initial termination point, even within internal networks, but they do so in different ways, each with its own trade-offs.

SSL/TLS Bridging

SSL/TLS Bridging is a pattern in which encrypted traffic is terminated at an intermediary (a load balancer), inspected or processed, and then re-encrypted before being forwarded to the backend application.

By decrypting traffic, the load balancer gains visibility into the HTTP layer. After processing, it establishes a new TLS connection to the backend, which may terminate TLS itself, delegate it to a local proxy, or accept plain HTTP within a trusted network.

SSL/TLS Passthrough

TLS Passthrough takes a different approach. The load balancer never decrypts traffic. Instead, encrypted traffic is forwarded directly to the destination server, where the TLS handshake is completed, and decryption occurs. This is end-to-end encryption. Because the load balancer never sees plaintext traffic, the responsibility for TLS is pushed entirely onto the backend server. This means the server must be configured with its own certificate and private key and must handle the full TLS lifecycle itself.

At this point, the server has a few options. It can terminate TLS directly within the application (for example, an app server listening on port 443), or offload decryption to a local reverse proxy such as Nginx or Traefik.

Conclusion

Each of these sections could easily be its own post, but working through them together helped solidify my understanding of how traffic traverses across applications. What started as a simple question—“Where does TLS termination happen?”—forced me to slow down and reason about the full request path instead of relying on assumptions.