Forum Discussion
PeterKoine_1630
Nimbostratus
NimbostratusIssue 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
SynACk_128568Cirrostratus
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_1630Hi 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_ParkerCirrus
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_1630Thanks 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
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_1630Hi 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
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_1630what 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
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_1630Hi 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_128568thanks for your inputs Peter , will check and revert back if i find some solution
- SynACk_128568
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 disaleOn 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_1630Hi 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_128568still need to perform the change . will keep thread posted
- SynACk_128568
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_1630Hi SynACk, setting "DEFAULT:+SHA:+3DES:+kEDH" under the monitor should do the trick i would say.
- Anesh
@SynAck Did the change suggested by F5 fix the issue?