Forum Discussion

Adam_187298's avatar
Adam_187298
Icon for Nimbostratus rankNimbostratus
Feb 26, 2015

HTTPS monitor configuration and TLS on v10.2.4 HF10

Hi. We are trying to configure a health monitor to use TLSv1, TLSv1.1 & TLSv1.2 instead of SSLv3 but are having issues getting the monitor to respond. Using ssldump from the LTM command line shows a handshake failure as follows:

 

1 1 0.0020 (0.0020) C>S SSLv2 compatible client hello Version 3.1 cipher suites TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xff 1 2 0.0032 (0.0011) S>CV3.1(2) Alert level fatal value handshake_failure 1 0.0032 (0.0000) S>C TCP FIN 1 0.0041 (0.0009) C>S TCP FIN

 

I have read previous questions on the subject but they all appear to be for v11.x and we are running v10.2.4 HF10 on our load balancers. IF we change the server to listen on SSLv3 then the monitor comes straight up and ssldump reports a successful handshake.

 

Our monitor is a HTTPS monitor with a simple Send and Receive string configured and we have tried it with the default ciphers of "DEFAULT:+SHA:+3DES:+kEDH" or included TLS related ciphers without success.

 

Please can someone help?

 

application delivery
availability
LTM

1 Reply

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Feb 26, 2015

    It does solve your issue (which perhaps isn't solvable with this version) but see this article: https://devcentral.f5.com/articles/cve-2014-3566-removing-sslv3-from-big-ip

     

    Quote:

     

    Outbound connections Many outbound connections are made by BIG-IP, including monitors. These may use SSLv3, but are not full fledged browsers and make single connections rather than the multiple transactions required for the attack. We believe these connections are not vulnerable.

     

    Based on information here: https://support.f5.com/kb/en-us/solutions/public/11000/400/sol11444.html there are only two ciphers that are exclusively non SSLv3. Perhaps try the NATIVE cipher string and see if that helps, although it looks to me like the two stated are included in your current cipher string.

     

    I wonder if your server implementation actually has the necessary support?