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 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.

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.

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

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.

Issue changing TLS version in HTTPS monitor

17 Replies

SynACk_128568
Cirrostratus
Jan 22, 2015
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
PeterKoine_1630
Nimbostratus
Jan 22, 2015
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
  Cirrus
  Jan 22, 2015
  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
  Nimbostratus
  Jan 22, 2015
  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 :).
SynACk_128568
Cirrostratus
Jan 28, 2015
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
  Nimbostratus
  Jan 28, 2015
  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.
SynACk_128568
Cirrostratus
Jan 28, 2015
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
  Nimbostratus
  Jan 28, 2015
  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.
SynACk_128568
Cirrostratus
Jan 28, 2015
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
  Nimbostratus
  Jan 29, 2015
  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
  Cirrostratus
  Jan 29, 2015
  thanks for your inputs Peter , will check and revert back if i find some solution
SynACk_128568
Cirrostratus
Jan 30, 2015
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
  Nimbostratus
  Jan 30, 2015
  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?
- SynACk_128568
  Cirrostratus
  Jan 30, 2015
  still need to perform the change . will keep thread posted
SynACk_128568
Cirrostratus
Feb 04, 2015
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
  Nimbostratus
  Feb 05, 2015
  Hi SynACk, setting "DEFAULT:+SHA:+3DES:+kEDH" under the monitor should do the trick i would say.
Anesh
Cirrostratus
Feb 06, 2015
@SynAck Did the change suggested by F5 fix the issue?

Forum Discussion

Issue changing TLS version in HTTPS monitor

17 Replies

Recent Discussions

BIG-IP DNS: Check Status Of Multiple Monitors Against Pool Member

Open Redirection Mitigation

F5Access | MacOS Sonoma

enable tls1.2 on management interface on F5 ltm running version 10.x

[ASM] - what is "Browser Challenge file" ?

Related Content

Using Cloud Templates to Change BIG-IP Versions - Azure

How to change TLS version 1.0 settings to version 1.2 or 1.3 in F5 DDoS product

Using Cloud Templates to Change BIG-IP Versions - AWS

Using Cloud Templates to Change BIG-IP Versions - Google GCP

Using Cloud Templates to Change BIG-IP Versions - Concepts