TLS passthrough on a layer 7 load balancer

John asked:

Trying to understand some fundamentals.

If I want a load balancer for the benefits of caching and more intelligent load balancing, I see that I should probably consider L7 despite some of the performance hit I’ll take no sticking with standard TCP/IP communication.

Now, let’s say I have TLS termination at the LB level, however, I still want TLS communication from the LB communication to the micro-service or downstream server I’m communicating with.

Is the flow like so:

  1. Client makes request to
  2. TLS handshake begins by sending serverHello to load balancer, which then proxies the serverHello to the backend application.
  3. Without writing all the steps, I’m assuming the entire TLS handshake takes place with the LB as an intermediary, but with this idea that the LB itself is doing this kinda of separate TLS handshaking process and encryption + decryption with the downstream server.

Is that a correct line of thinking and is this how it works in the real world?

I personally am conceptualizing this as something you’d want because the communication from the LB to the service could cross boundaries of separate servers over a network, so you’d have a second TLS connection to avoid packet sniffing after the second connection is made.

My answer:

If you’re doing layer 7 (regardless of TLS termination) then the incoming connection terminates at the load balancer. The LB opens a completely new connection to your backend server, the lifetime of which is entirely independent from any client connections. The LB will then pass requests over that connection to your backend, if it doesn’t handle them itself (e.g. by sending a cached response).

P.S. Your direction is reversed: downstream is toward the user agent, and upstream is toward your backend server.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.