Forum Discussion

Not_The_Good_Ke's avatar
Not_The_Good_Ke
Icon for Altocumulus rankAltocumulus
Sep 05, 2017

SSL decryption/re-encryption w/iRule feeding into HTTPS load balance

Hi Folk,

 

I'm attempting to set up SSL interception on a pair of F5 LTM in our DMZ that will feed into a second pair of F5 that is load balancing the HTTPS session internally on our network.

 

Internally the load balancing works correctly. We have two servers listening for HTTPS on port 8443 behind a virtual server performing "Performance(Layer 4)" type load balancing, also listening on port 8443.

 

I'm running into an issue on the outside F5s. Externally I have a virtual server set up listening on port 8443 that will use the internal F5 VIP as its destination. I'm using type "Standard" so I can set up the SSL profiles. I have imported the server cert and have created a client side SSL profile using that cert, and have created a server SSL profile using a self signed cert. I have also created an iRule that is intended to block all traffic except for Android and iOS devices based on the OS provided by the User-Agent.

 

It doesn't seem that I'm able to connect the two sides of the SSL conversation together to apply the iRule. I find that if I enable the client side profile I see the F5 presenting the server cert, but I don't see anything coming back from the server itself (likely because it's expecting encrypted traffic and I'm sending clear text). If I disable the client side and enable the server side it seems that I can reach the server and it presents the expected page. So it seems that individually both sides work. When I enable both the connection breaks and i'm not able to reach the server. This is without applying the iRule yet so I know it's not the source of the problem.

 

Currently I've removed the SSL client and server side profiles, and I can connect without any issues externally, but I need to get the iRule in so I can't leave it in this configuration.

 

Anyone have any thoughts about setting up SSL decryption/re-encryption that might point me to a solution to this problem?

 

application delivery
LTM
security
ssl
  • Not_The_Good_Ke's avatar
    Not_The_Good_Ke
    Nov 01, 2017

    I was able to get the service working after discovering the issue using tcpdump to capture the full flow of traffic.

     

    What I found was the client side SSL profile was working correctly, the LTM was intercepting the traffic and was decrypting the flow, and was using TLS 1.2. However when the LTM’s server side profile negotiated SSL with the server it was somehow settling on TLV 1.0, which the server rejected. I changed the cipher list in the SSL server profile to only use TLS 1.2 and everything worked.

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Sep 05, 2017

    I don't follow a couple of things with this setup.

     

    1. Why do you have a cert on the server ssl profile? Does the internal SSL require a client cert? or are you verifying the internal server certs (i.e. using the self-signing cert as the CA on the server ssl profile)

       

    2. What makes you think you're sending traffic cleartext from the external BigIP to the internal?

       

    3. You say you see the external BigIP presenting the cert from the client ssl profile. But does the negotiation complete? And does the request actually get sent?

       

    From your description... I think what's happening is the client ssl profile negotiation isn't completing. You make no mention of the request actually coming through to the external BigIP, Which is required BEFORE the external BigIP will open a connection to the internal BigIP...

     

    What are you testing with? curl? openssl and typing the request by hand? a browser? I'd recommend openssl myself... Or curl if you aren't comfortable with that. It'll give you a much better sense of what's happening on the external-client side of the connections.

     

    H

     

  • Not_The_Good_Ke's avatar
    Not_The_Good_Ke
    Icon for Altocumulus rankAltocumulus
    Nov 01, 2017

    I was able to get the service working after discovering the issue using tcpdump to capture the full flow of traffic.

     

    What I found was the client side SSL profile was working correctly, the LTM was intercepting the traffic and was decrypting the flow, and was using TLS 1.2. However when the LTM’s server side profile negotiated SSL with the server it was somehow settling on TLV 1.0, which the server rejected. I changed the cipher list in the SSL server profile to only use TLS 1.2 and everything worked.