Hello, I have a problem with the HTTPS monitor. When no monitor, the traffic is transmitted, and I can see a successfull SSL handshake between F5 and the client, and F5 and the server, using TLSv1.2 (Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) with the server ) However, whith HTTPS monitor activated, F5 Client Hello uses TLSv1.2 with the same cipher suite, but the server returns Alert Message Description: Handshake Failure (40). I tried with "ALL" in the cipher list of SSL monitor, no change in the negotiation. I have no debug log. Have you any trail for me?

The HTTPS monitor run in bigd, which uses the OpenSSL cipher suite(COMPAT). Your client and server SSL profiles use the NATIVE cipher suites. Your handshake failure suggests no overlap in cipher suites. I would verify via packet capture that the cipher list sent by the monitor has overlap with your server. What BigIP version are you running? I wonder if the problem you are having with TLSv1.2 in the OpenSSL cipher suite is similar to what I have found with iControl stuff not working with TLSv1.2.

Hi Brad, The cipher used between F5 and the server when no monitor is 0x009c. This cipher is in the F5 client Hello monitor too. I'm running LTM v11.6

Would it be possible to post the client hello packet from both the profile handshake and the https monitor attempt, sanitized of course if needed. I'm interested to see the difference. I've been bird dogging a problem with TLSv1.2 and iControl functions.

Here is the capture when no monitor, the server answers correctly And here is the capture when the monitor is activated, the server sends back fatal error:

I've seen this before. It may be an issue with openssl on BigIP or the SSL stack on your server. In this case, the SSL stack on your server doesn't like the version differences in the handshake envelope. Even though it is "complaint" by RFC standards, I've seen more than one server fail handshakes with this behavior. As you can see the monitor is sending a version TLS 1.2 handshake inside of a Client Hello mark with version TLS 1.0. Your server probably wants those to match. Unfortunately, I'm not sure if there's a way on your end to change that behavior in the monitor.

Handshake SSL failed for the HTTPS monitor

Brad_Parker
Cirrus
Mar 03, 2015
The HTTPS monitor run in bigd, which uses the OpenSSL cipher suite(COMPAT). Your client and server SSL profiles use the NATIVE cipher suites. Your handshake failure suggests no overlap in cipher suites. I would verify via packet capture that the cipher list sent by the monitor has overlap with your server.

What BigIP version are you running? I wonder if the problem you are having with TLSv1.2 in the OpenSSL cipher suite is similar to what I have found with iControl stuff not working with TLSv1.2.
Merry95_171142
Nimbostratus
Mar 03, 2015
Hi Brad,

The cipher used between F5 and the server when no monitor is 0x009c. This cipher is in the F5 client Hello monitor too.

I'm running LTM v11.6
- Brad_Parker
  Cirrus
  Mar 03, 2015
  Would it be possible to post the client hello packet from both the profile handshake and the https monitor attempt, sanitized of course if needed. I'm interested to see the difference. I've been bird dogging a problem with TLSv1.2 and iControl functions.
Merry95_171142
Nimbostratus
Mar 04, 2015
Here is the capture when no monitor, the server answers correctly

And here is the capture when the monitor is activated, the server sends back fatal error:
Brad_Parker
Cirrus
Mar 04, 2015
I've seen this before. It may be an issue with openssl on BigIP or the SSL stack on your server. In this case, the SSL stack on your server doesn't like the version differences in the handshake envelope. Even though it is "complaint" by RFC standards, I've seen more than one server fail handshakes with this behavior. As you can see the monitor is sending a version TLS 1.2 handshake inside of a Client Hello mark with version TLS 1.0. Your server probably wants those to match. Unfortunately, I'm not sure if there's a way on your end to change that behavior in the monitor.
- Adrian_P
  Nimbostratus
  Jul 03, 2015
  Hi Brad, I am having the same issue while configuring HTTPS monitor. The Client Hello from the F5 monitor have mismatched TLS version on the Handshake (TLS 1.0) and Handshake protocol (TLS 1.2) and the server send a RST, ACK straight away. Is this behaviour is going to be fixed in the next release ? We are running 11.6.0 Engineering Hotfix Version 4.107.420
- DMA_95966
  Nimbostratus
  May 21, 2016
  Hi Brad , Just checking if there is any solution for this, i am also facing same issue .
Brad_Parker_139
Nacreous
Mar 04, 2015
I've seen this before. It may be an issue with openssl on BigIP or the SSL stack on your server. In this case, the SSL stack on your server doesn't like the version differences in the handshake envelope. Even though it is "complaint" by RFC standards, I've seen more than one server fail handshakes with this behavior. As you can see the monitor is sending a version TLS 1.2 handshake inside of a Client Hello mark with version TLS 1.0. Your server probably wants those to match. Unfortunately, I'm not sure if there's a way on your end to change that behavior in the monitor.
- Adrian_P
  Nimbostratus
  Jul 03, 2015
  Hi Brad, I am having the same issue while configuring HTTPS monitor. The Client Hello from the F5 monitor have mismatched TLS version on the Handshake (TLS 1.0) and Handshake protocol (TLS 1.2) and the server send a RST, ACK straight away. Is this behaviour is going to be fixed in the next release ? We are running 11.6.0 Engineering Hotfix Version 4.107.420
- DMA_95966
  Nimbostratus
  May 21, 2016
  Hi Brad , Just checking if there is any solution for this, i am also facing same issue .
RLU5
Altostratus
Apr 27, 2018
Hi Brad, I am having similar issue with 12.1.3. Wondering you have any update for this?