Forum Discussion

PeterKoine_1630's avatar
PeterKoine_1630
Icon for Nimbostratus rankNimbostratus
Jan 22, 2015

Issue changing TLS version in HTTPS monitor

Hello everyone,

 

I am having troubles to change the cipher suite on a custom https monitor. Our client has turned off TLS v1.0 on their servers but each time I change the cipher option from DEFAULT ie. to DEFAULT:!SSLv3:!TLSv1 (worked on serverssl profile) to limit it to TLS v1.1 and TLS v1.2 no SSL session is being established for the monitor (I'm checking it with ssldump on the LTM, we use v10.2.4). Actually it just receives TCP fin and TCP resets messages. As soon as I put DEFAULT back, without disabling any other versions, I immediately start to see SSL sessions building up (and denied by server) using TLS v1.0. The only thing I can tamper with are the hashing/encryption/authentication algorithms, like ie DEFAULT:!RC4:!AES. This works as expected. But disabling the whole version stops creating ssl sessions.

 

Is it somehow enforced/hard-coded? And can it be changed?

 

Thanks.

 

  • Hi Peter ,

     

    https monitor uses openssl library and openssl flags sslv3 and tls1.0 same . So when you use DEFAULT:!SSLv3:!TLSv1 there are no ciphers left to negotiate .

     

    have you tried

     

    tmsh modify ltm monitor https monitor_name cipherlist TLSv1 or someother version .

     

    you can see openssl ciphers by using this command :

     

    openssl -v DEFAULT or some other setting in cipherlist in monitor https

     

  • Hi Peter ,

     

    https monitor uses openssl library and openssl flags sslv3 and tls1.0 same . So when you use DEFAULT:!SSLv3:!TLSv1 there are no ciphers left to negotiate .

     

    have you tried

     

    tmsh modify ltm monitor https monitor_name cipherlist TLSv1 or someother version .

     

    you can see openssl ciphers by using this command :

     

    openssl -v DEFAULT or some other setting in cipherlist in monitor https

     

  • Hi SynACk,

     

    Thanks for the reply.

     

    I've tried to set it as TLSv1_2 directly, but no sessions were opened. But if the https monitor doesn't actually use the build-in ciphers, the native ones like server/client ssl profiles do (which I checked via "tmm --serverciphers 'DEFAULT'" and they do support TLSv1.2 ie), and uses openssl instead then that would make perfect sense. The build in version of openssl in this particular version we are running is 0.9.8e. TLSv1.2 is supported from version 1.0.1 I believe. Now, this is kind of disappointing, would really like to know why the native ones are not used instead. Or at least to have a option to choose them somehow.

     

    Anyway, thanks for the help.

     

    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      I believe the big3d service is what monitors pools and nodes and it uses OpenSSL just like the httpd service. The Native ciphers live in TMM and were designed to be hardware accelerated for production traffic. I hope this helps a bit. from a bash prompt you can run "openssl ciphers" to view the ciphers available in the runnig version of Openssl and test your cipher string similar to tmm --serverciphers.
    • PeterKoine_1630's avatar
      PeterKoine_1630
      Icon for Nimbostratus rankNimbostratus
      Thanks Brad. This difference should be mentioned somewhere on F5 web page I believe. I checked the bigd process and it just mentioned that it is used by monitors and nothing else, neither was it mentioned on pages related to https monitors. To me it looks quite important :).
  • Hi Peter/Brad,

     

    i also had a somewhat similar issue few days back , maybe you can tell if you faced same issue .

     

    LTM has default cipherlist in https monitor . And team who manages backend servers disabled sslv2 ,sslv3 . After that LTM is marking pool member down .

     

    when using curl command it reported wrong version used, handshake failure .

     

    Any help will be appreciated . No changes done on LTM .

     

    Thanks

     

    • PeterKoine_1630's avatar
      PeterKoine_1630
      Icon for Nimbostratus rankNimbostratus
      Hi SynACk, I assume you ran curl from the F5 directly. Most likely it does not support more than TLS1.0. In any case, can you run ssldump from the F5 ('ssldump -i 0.0 -AnNd host xxxx and port 443' ) to that pool member? This way you can at least see if a SSL session is being established and at which point it fails. Also, it helped me to download latest curl. I then ran it from one of our jump servers to see if at least TLS1.1/2 negotiates correctly. In my case i.e., when customer disabled TLS1.0 and realized it won't work at first, even when they've re-enabled it, monitor was still marking the pool down as there was no cipher that the F5 and their server could agree upon. None of the openssl DEFAULs matched their TLS1.0 cipher list profile. Would be worthwhile checking with them what kind of SSL settings they've kept enabled.
  • Hi Peter ,

     

    I ran ssl dump and it was something like this :

     

    self ip ltm <->backend server sslv2 compatible client hello

     

    Version 3.1

     

    all the cipher suites . . . .

     

    Backend server<->self ip TCP Fin

     

    self ip<->backend sevrer TCP Fin

     

    Thanks

     

    • PeterKoine_1630's avatar
      PeterKoine_1630
      Icon for Nimbostratus rankNimbostratus
      what did the server hello message say? Does the handshake look similar to this one? 1 1 0.0020 (0.0020) C>S SSLv2 compatible client hello Version 3.1 cipher suites cipher 1 cipher 2 ... 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 In this case ie, ssl version matched but there was no match in the cipher list, so the session was torn down. if you see '1 2 0.0032 (0.0011) S>CV3.2(2) Alert' on the other hand, then ssl version does not match.
  • Hi Peter,

     

    It was like this :

     

    1 1 0.0020 (0.0020) C>S SSLv2 compatible client hello

     

    Version 3.1

     

    cipher suites

     

    cipher 1

     

    cipher 2 . .

     

    1 0.0032 (0.0000) S>C TCP FIN

     

    1 0.0041 (0.0009) C>S TCP FIN

     

    Thanks

     

    • PeterKoine_1630's avatar
      PeterKoine_1630
      Icon for Nimbostratus rankNimbostratus
      Hi SynACk, that is quite odd. It seems server is not responding at all. Hasn't your server team disabled all ssl options? Like when i did in my original question about https where it was not sending anything but tcp rst and fin with DEFAULT:!SSLv3:!TLSv1 set up. As per RFC anyway: The server will send this message in response to a client hello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert. So if it has at least something enabled, it should respond either with an alert or success message. Unfortunately i do not have access to some backend server i could test my theory on. I was somewhat able to mimic it by disabling all ciphers on clientssl profile. VIP didn't respond at all and curl showed this: * SSLv2, Client hello (1): Unknown SSL protocol error in connection to xxx:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to xxx:443
    • SynACk_128568's avatar
      SynACk_128568
      Icon for Cirrostratus rankCirrostratus
      thanks for your inputs Peter , will check and revert back if i find some solution
  • Hi Peter,

    We checked and got a solution from F5 :

    once the server negotiates from SSLv2 to TLS1, all subsequent connections will utilize the later protocol. Due to the fact that these pool members have already negotiated to TLSv1, some of the monitors are shown working to pool members with sslv2 disabled .

    basically they told that LTM cannot perform negotiate .

    They recommended to disable :

    app-service none
    cert none
    cipherlist DEFAULT:+SHA:+3DES:+kEDH
    compatibility enabled  <---try setting compatibility to disale  
    

    On F5 documents compatibility Displays, when enabled, that the SSL options setting (in OpenSSL) is set to ALL. The default is Enabled.

    Not able to understand it's purpose ?

    Thanks

    • PeterKoine_1630's avatar
      PeterKoine_1630
      Icon for Nimbostratus rankNimbostratus
      Hi SynACk, the compatibility setting is about turning on openssl's bug workarounds https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html During an ssl session handshake, in the client hello message, the client sends all the ciphers it supports and mentions the highest ssl version it can use. Server should always choose the strongest compatible. So yes, if you have SSLv2 and TLS1 enabled, TLS1 should always be chosen in all future connection. But haven't you mentioned that you have SSLv2 and SSLv3 disabled on the servers? Also, has turning off compatibility solved the issue you have?
  • Hi Peter ,

     

    is there any way to force bigd to use tlsv1 as starting cipher instead of using pseudo sslv2 client hello which is being just used for compatibility reasons.

     

    Thanks

     

    • PeterKoine_1630's avatar
      PeterKoine_1630
      Icon for Nimbostratus rankNimbostratus
      Hi SynACk, setting "DEFAULT:+SHA:+3DES:+kEDH" under the monitor should do the trick i would say.
  • Anesh's avatar
    Anesh
    Icon for Cirrostratus rankCirrostratus

    @SynAck Did the change suggested by F5 fix the issue?