Forum Discussion

sniffer_375425's avatar
sniffer_375425
Icon for Nimbostratus rankNimbostratus
Feb 01, 2019

Terminating SSL on F5 and re-encrypt to end server

Hello,

 

I need to use my F5 in next scenario:

 

Internet -> F5 -> WebApplicationProxy -> End node/server

 

On F5 i need to do ssl offload because i need to forward traffic based on information from header.

 

I configured both: SSL Profile Client and SSL Profile Server.

 

SSLDUMP F5 -> Server

 

New TCP connection 1: 10.99.11.36(11086) <-> 10.99.11.39(443)
1 1  0.0006 (0.0006)  C>SV3.1(139)  Handshake
      ClientHello
        Version 3.3
        random[32]=
          59 c2 05 9e 08 c6 ec ef d2 5b 61 82 23 8a 7e 21
          cc e3 0b a1 e4 fe c2 f6 bd b9 5d a4 f0 81 0d ff
        cipher suites
          TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
          TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
          TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
          TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
          TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
          TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
          TLS_RSA_WITH_AES_128_GCM_SHA256
          TLS_RSA_WITH_AES_128_CBC_SHA
          TLS_RSA_WITH_AES_128_CBC_SHA256
          TLS_RSA_WITH_AES_256_GCM_SHA384
          TLS_RSA_WITH_AES_256_CBC_SHA
          TLS_RSA_WITH_AES_256_CBC_SHA256
          TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
          TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
          TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
          TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
          TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
          TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
          TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
          TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
          TLS_EMPTY_RENEGOTIATION_INFO_SCSV
        compression methods
                  NULL
        extensions
          supported_groups
          ec_point_formats
          signature_algorithms
            signature_algorithms[26]=
              04 01 05 01 06 01 04 02 05 02 06 02 04 03 05 03
              06 03 02 01 02 02 02 03 01 01
          extended_master_secret
1    0.0012 (0.0006)  S>C  TCP RST

I also have one very strange situation, i did openssl from client and i get this: This is done when i configured F5 just to forward traffic no ssl offloding

 

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1549020813
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

Does anyone have idea what to do?

 

Thanks.

 

6 Replies

  • Hy Pete, yes of course, i did ssl handshake on External interface when i am doing ssl offloading and that is working fine.

     

    I also have VS where i am ssl offloading and based on header i am doing redirect. But the problem is when i need to re-encrypt end send to server behind f5.

     

  • wlopez's avatar
    wlopez
    Icon for Cirrocumulus rankCirrocumulus

    Can you explain the error in more detail?

     

    Are you getting a specific error message?

     

    If you're doing ssl bridging, both client and server ssl profiles on the virtual server, there will be two separate handshakes for all traffic. Each one is independent from the other and will be handled by whatever settings you have on each ssl profile. The client ssl profile needs to complete the handshake successfully with the user. Once that happens then the handshake against the selected pool member(s) begins.

     

    If you believe your situation is ssl related you may probably need to capture both handshakes.

     

  • So when you re-encrypt you need to add a serverSSL profile to re-encrypt the data. Make sure that the pool member is listening on port 443. When doing SSL offloading, the clientside port is 443 ie SSL and the serverside port is 80 so you may need to change that when changing to SSL bridging.

     

  • Pete, i didn't catch you with this serverside is port 80 and SSL bridging.

     

    Let me explain my situation.

     

    I need next case in traffic flow:

     

    Client -> F5 (here i am doing ssl offload with configured SSL Profile Client) -> pull header and based on that forward to some pool also 443 -> then WebApplicationProxy (here after user is auth ) -> End server

     

    1. Client on Internet request https://abc.abc.com
    2. It's reaching my F5 where i configured VS with SLL Profile Client (i added certificate and private key) and with port 443.

    2.1 here i checked SSL handshake between client and F5(server in this case) and everything is working fine.

     

    3 After i match my request with iRule i forward to Pool in witch i have WebApplicationProxy port 443.

     

    3.1 Mention VS is also configured with SSL Profile server

     

    3.2 Now when i check SSL handshake between F5 (client this time) and server (WAP) i have output from my original post. Server immediately send TCP restart (i checked cipher from side client-F5 and same is sent from F5 to WAP)

     

    3.3 When i check this WAP server and do netstat i don't see any connection coming and yes this WAP listening on port 443

     

    Also i use http profile in VS

     

    So i know that i am doing something wrong on side when i need to re-encrypt but don't know what.

     

    Second scenario

     

    When i don't use ssl offloading and create VS that listen on 443 and just forwarding on same pool that i use in above explained scenario (without SSL Profile Server/Client) everything is working fine.

     

    Thanks a lot guys for help.

     

  • Hello Ivan,

    My instinct is that there's an issue with your server-side SSL certificate, either in configuration or connectivity. Based on your SSL dump from your F5 to your server, the client hello seems to be in order, sending accepted TLS ciphers, compression, algorithms, etc. But at the very bottom of the dump you shared there is:

    1    0.0012 (0.0006)  S>C  TCP RST
    

    That looks like a reset. i.e. your F5 did not get a response from your backend server, and is restarting the ssl exchange. I'm guessing layer 4 connectivity isn't the problem, since when you offload encryption on the F5 it worked as intended.

    The openssl from client through the F5 and straight to your backend servers seems to support this idea as well. The SSL handshake is failing in a nigh identical way in this set-up; there seems to be no response from the server, which should decide on which ciphers/compression will be supported. I based this off of:

    no peer certificate available
    ---
    No client certificate CA names sent
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    

    Based on the information from the ssl dump between the F5 and the back-end server, it makes sense that the certificate exchange fails, since it looks like there isn't even a Server Hello in response to the CLient Hello.

    To troubleshoot, I would potentially double-check how your proxy is functioning between the F5 and the backend-servers; it could be blocking the server hello in some way. Else, maybe there's an issue with your server ssl cert.

    Hope that gives you some ideas,

    Austin