Hi folks - I have a strange situation and I was hoping to understand better what is going on.
I have an older LTM, it's a Viprion chassis with a 2100 blade - both the chassis and the blade are running on the now obsolete TMOS v11.4.1.
I have a Virtual Server with both a Client Side SSL Profile and a Server Side SSL Profile. For my Server Side SSL Profile, I have added a Certificate and Key but I have disabled Server Authentication. For my Client Side SSL Profile, I have added a Certificate, Key, Trusted Certification Authority, and I have also edited the Ciphers list and the Options List such that only TLSv1.2 AES ciphers are allowed.
My question has to do with Server Side SSL - my understanding to date has been that when a client connection arrives at a Virtual Server which has both the Client SSL Profile and the Server SSL profile attached, the LTM first terminates the Client Side SSL connection at the TMM layer. Then as the Virtual Server has a Server SSL Profile attached to it, the LTM tries to establish an SSL connection to the Pool Member - but when the LTM tries to do this, it is not TMM that initiates the connection to the Pool Member but instead it is the OpenSSL included in TMOS that acts as the client for the Server Side connection.
Therefore, my understanding was that the TLS version supported at the server side has always been dependent on the TLS versions that are supported by the OpenSSL version included in the release of TMOS.
# Question No.1 - is this understanding correct or have I been mistaken all this while?
Looking at my TMOS v11.4.1 on Article K14457, the OpenSSL version included in this release of TMOS is 0.9.8y, and this version of OpenSSL does not support TLSv1.2. But the weird thing is that the web servers which I have in my Pool has been configured to disable all but TLSv1.2 AES ciphers and the communication works! It should not work as the SSL Handshake should fail when OpenSSL tries to connect.
I tried to verify my understanding by heading over to the Advanced Shell and doing a cURL to the Pool Member in question, and as expected - the connection fails with an SSL Handshake Error - indicating that indeed the OpenSSL version that the LTM runs does not support TLSv1.2.
I then also did an OpenSSL test using "openssl s_client -connect x.x.x.x" to the Pool Member in question, and again as expected the connect failed with an error of "Unknown Protocol".
Still not satisfied, I also used an SSL scanning tool to ensure that the web server does in actual fact support TLSv1.2 only - and true enough, the server only supported TLSv1.2.
Which brings me to...
# Question No.2 - What's going on and how is my communication working?
If you are using SSL profile, BIG-IP uses tmm ciphers. So, serverside SSL uses tmm ciphers.
To check tmm ciphers, from bash we can use command, tmm --serverciphers 'DEFAULT' or the ciphers you have specified in serverside profile. Similar command tmm --clientciphers 'DEFAULT'
In versions 11.x the monitors use openssl.
Oh! Does that mean that in versions 11.x, when the LTM tries to establish server side SSL connections it actually uses the TMM to initiate and not OpenSSL?
And that only the monitors use OpenSSL to make the connection for health monitoring?
This makes a lot of sense if it's the case 😄