IBM Security Verify

 View Only
Expand all | Collapse all

SSL connection to Reverse Proxy using Load Balancer

  • 1.  SSL connection to Reverse Proxy using Load Balancer

    Posted Wed May 05, 2021 03:19 PM
    The ISVA Load Balancer is responding on port 443, and it forwards the request to the Reverse Proxy Cluster members.
    Reverse Proxies are configured to accept SSL connections on ports 443 too.

    If the Load Balancer is using Layer 4, is in fact not using SSL.
    On the Real Servers configuration, we must use port 443 to access the reverse proxies, and there is an options to use SSL connection. This option is for the communication between Load Balancer and Real Servers.

    So, how does this work? Load Ballancer accepts SSL connections, and since it is configured as layer 4. Does the LoadBalancer proxies the Reverse Proxies? Passthrough the connection? I believe this is how it should work, but would like to understand how ISVA behaves.

    Thanks

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    ------------------------------


  • 2.  RE: SSL connection to Reverse Proxy using Load Balancer

    Posted Thu May 06, 2021 05:59 AM
    Hi Joao,

    When the ISVA Front-end  load-balancer (FELB) is working at layer 4, it is reading and forwarding TCP packets.  A layer 4 load-balancer doesn't break an SSL session.  This means that the SSL session is still end-to-end between the client and the target server.  A layer 4 load balancer can't see or modify anything above layer 4 so it can't be "sticky" based on a cookie (because it can't see or inject into HTTP stream).  Usually layer 4 load balancing is done based on (physical) source IP which is often not very good when dealing with a large number of clients behind a NAT gateway (or similar).

    When the ISVA FELB is working at layer 7 it needs to see (and manipulate) the HTTP traffic.  For this reason, it must terminate the SSL session.  Depending on configuration it may forward traffic to target servers over HTTP (SSL-offload) or it may have a new SSL session to the target server.

    A layer 7 load-balancer can inject a cookie into responses to uniquely tag the connecting device.  This allows a layer 7 load-balancer to perform "stickiness" for each individual client regardless of network architecture.  In my opinion, this is the main reason to use layer 7 vs layer 4.

    Because the whole connection stack is terminated at a layer-7 load-balancer, it must forward information about the original connection to the target server if this is need for target server processing.  For example, it might forward the original IP address or information about a received client certificate in HTTP headers.  Dealing with this need to handle the lower-level communication and forward results (and the overhead this implies) is the "downside" of a layer 7 load-balancer.

    This is a good topic in the IBM Docs: https://www.ibm.com/docs/en/sva/10.0.1?topic=administration-front-end-load-balancer

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message