cancel
Showing results for 
Search instead for 
Did you mean: 

F5 LTM version 12.1.2 HTTPS monitor uses TLSv1 - No Client and server SSL profile

HM_U333
Altocumulus
Altocumulus

I need suggestion to fix the issue i'm facing.

Device details: Version 12.1.2, Build 1.0.271, Edition Hotfix HF1

1. No Client and Server SSL profile associated to 'Standard' Vs.

2. Pool member is on 443 port and associated HTTPS monitor.

3. Ciphers - DEFAULT:+SHA:+3DES:+kEDH and under 'Client Cert' and 'Client Key' i have tried using different SSL cert. Still same error and same issue in pcap.

4. Im seeing F5 using TLSv1 protocol for 'Client Hello' in PCAP and server is not responding with 'Server Hello', Server send RST message immediately.

Openssl and curl o/p is as below:

>>Used ab.c.d for my pool member IP.

Command 1 - # openssl s_client -connect a.b.c.d:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 277 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Command 2:  # curl -I https://a.b.c.d/ForwardSearchOrderSend.svc
curl: (35) Unknown SSL protocol error in connection to a.b.c.d:443


 Command 3:  # curl -Ivk https://a.b.c.d/ForwardSearchOrderSend.svc
* About to connect() to a.b.c.d port 443 (#0)
* Trying a.b.c.d... connected
* Connected to a.b.c.d (a.b.c.d) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to a.b.c.d:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to a.b.c.d:443

 

5.  I have checked below articles- Still no use.

https://community.f5.com/t5/technical-forum/f5-server-ssl-profile-using-tls-1-0-instead-of-tls-1-2/m... 

https://community.f5.com/t5/technical-forum/f5-health-monitor-suddenly-use-tlsv1/td-p/213711 

6.  To check with server team about server cert, They rasied question about F5 using 'TLS v1' for 'Client Hello'.

7. Server has Private Interface and Public Interface. Via Public Interface HTTP monitor is working for one application. We want to monitor different App using HTTPS via Private interface.

Can someone suggest whats casuing HTTPS to fail as its old version and no SSL profile, im bit confused.

11 REPLIES 11

Interesting problem. I have no suggestion but questions. 

You say you do not use any client, nor server ssl profiles. In that case the device should not intercept any SSL at all.
However, you also say you use an HTTPS monitor and this one would try to establish a TLS session when connecting to the pool member. A few questions:

Where are the ciphers you mentioned configured? The HTTPS monitor?

Can you run this command to check what Ciphers that equals?

tmm --serverciphers 'DEFAULT:+SHA:+3DES:+kEDH'

 I am not sure if 12.1.2 supports TLS1.2 and if the member server is patched and hardened you might have an issue during the cipher negotiation. Try changing the monitor to TCP to rule it out?

Kind regards,
Patrik

Hello Patrik, Thanks for inputs.

Here are details about Ciphers. This confirms we have TLSv1.2 Ciphers too.

Spoiler
# tmm --serverciphers 'DEFAULT:+SHA:+3DES:+kEDH'
ID SUITE BITS PROT METHOD CIPHER MAC KEYX
0: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA
1: 158 DHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 EDH/RSA
2: 107 DHE-RSA-AES256-SHA256 256 TLS1.2 Native AES SHA256 EDH/RSA
3: 103 DHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 EDH/RSA
4: 157 AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 RSA
5: 156 AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 RSA
6: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA
7: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA
8: 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA
9: 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA
10: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDHE_RSA
11: 49191 ECDHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 ECDHE_RSA
12: 57 DHE-RSA-AES256-SHA 256 TLS1 Native AES SHA EDH/RSA
13: 57 DHE-RSA-AES256-SHA 256 TLS1.1 Native AES SHA EDH/RSA
14: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA
15: 57 DHE-RSA-AES256-SHA 256 DTLS1 Native AES SHA EDH/RSA
16: 51 DHE-RSA-AES128-SHA 128 TLS1 Native AES SHA EDH/RSA
17: 51 DHE-RSA-AES128-SHA 128 TLS1.1 Native AES SHA EDH/RSA
18: 51 DHE-RSA-AES128-SHA 128 TLS1.2 Native AES SHA EDH/RSA
19: 51 DHE-RSA-AES128-SHA 128 DTLS1 Native AES SHA EDH/RSA
20: 53 AES256-SHA 256 TLS1 Native AES SHA RSA
21: 53 AES256-SHA 256 TLS1.1 Native AES SHA RSA
22: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA
23: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA
24: 47 AES128-SHA 128 TLS1 Native AES SHA RSA
25: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA
26: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA
27: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA
28: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA
29: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 Native AES SHA ECDHE_RSA
30: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.2 Native AES SHA ECDHE_RSA
31: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA
32: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.1 Native AES SHA ECDHE_RSA
33: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.2 Native AES SHA ECDHE_RSA
34: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA EDH/RSA
35: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA EDH/RSA
36: 22 DHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA EDH/RSA
37: 22 DHE-RSA-DES-CBC3-SHA 168 DTLS1 Native DES SHA EDH/RSA
38: 10 DES-CBC3-SHA 168 TLS1 Native DES SHA RSA
39: 10 DES-CBC3-SHA 168 TLS1.1 Native DES SHA RSA
40: 10 DES-CBC3-SHA 168 TLS1.2 Native DES SHA RSA
41: 10 DES-CBC3-SHA 168 DTLS1 Native DES SHA RSA
42: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1 Native DES SHA ECDHE_RSA
43: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.1 Native DES SHA ECDHE_RSA
44: 49170 ECDHE-RSA-DES-CBC3-SHA 168 TLS1.2 Native DES SHA ECDHE_RSA

>> Where are the ciphers you mentioned configured? The HTTPS monitor?

> In 12.1.2 HTTPS monitor intself has option to mention Cipher and cert. I have mentoned Ciphers there, No SSL cert mentioned. We have few other HTTPS monitors which is working for different servers/pool, i have compared the configurations, its same. Still this HTTPS monitor is not working.

As per Article 12.x has this option and i see in my 12.1.2 F5.  https://support.f5.com/csp/article/K51131340 

 

>> Server has Cert associated with Website. F5 sends 'Client Hello' but no server hello at all. Question is why F5 is sending via TLSv1. PCAP attached. After F5 sends Client Hello, 'SERVER' is sending RST as you see.

HM_U333_0-1661344114719.png

Any suggestions? What could be causing this issue?

 

See, in the Client Hello packet includes the list of protocol and ciphers that the client supports. My suspicion from the things you wrote above would be that the device (F5 BigIP) does not support the ciphers that the server requires.

Perhaps you can confirm this by checking the server config or run the tests from a functioning client and determine one of the supported ciphers from there. If you have no functioning client perhaps looking at the server SSL config would be in order.

Kind regards,
Patrik

Hello Patrick,

'Client hello' has same ciphers and Verson when compared with working and non-working. PFA snap. There are working HTTPS monitor. If you see previous snap, F5 Client Hello is via TLSv1. Why is that? There is no Server SSL profile, so In 12.1.2 version where can we control procol for SSL for HTTPS monitor?

Any suggestions?

Left-Non Working --- Right-Working.

HM_U333_1-1661360603337.png

 

 

Sorry for the short reply, I'm not by my PC. Working and not working above is two different servers and the f5 is the client right?

What I was requesting was a Server hello from the one that does not respond to the F5s monitors, but from another more modern client, like a Linux server with a newer version of curl. 

This issue could also be missning SNI info in the F5 monitor requests. I'd focus on the server cipher settings and I'd also check if the server needs SNI To route requests to the correct service. 

>> Working and not working above is two different servers and the f5 is the client right?

--- Yes. 2 different pool member, same F5 client. Related to 2 different VIP. Both using HTTPS monitor.

>>This issue could also be missning SNI info in the F5 monitor requests. I'd focus on the server cipher settings and I'd also check if the server needs SNI To route requests to the correct service. 

> Thanks for this, Im checking Ciphers. We dont have serverssl profile. How do we use SNI here?

>> If far end server doenst have ciphers which we support, do we get 'Server Hello' or we get RST? I just got confirmed with server team that same certificate is installed on server for 4 Apps. HTTPS connections working for other HTTPS communications. But not for F5 HTTPS monitor.

>> If i change the monitor to TCP, it works, URL is accesible via HTTPS. Its just that F5 HTTPS monitor not working.

Suggestions to check further are welcome.

On my mobile again. You're confusing ciphers with certificates. 

Very simplified but think of if it as certificates being the secrets and the  ciphers as the method of how these secrets are exchanged and how they're encrypted.

Thus a servers can use the same certificates but use different ways of handling the key exchange.

You're using an old version of TMOS and you need to figure out why the server does not accept your TLS handshake. 

The best way to do that would be to check these things:

  • Which cipher suite is the server using?
  • Does it depend on SNI?

You can see at least one of the server ciphers by doing the following:

Again, you're running an old version and a quick Googling told me that SNI support did not come until v13.

Good luck with the hmcioher hunt. Looking forward to the solution to this mystery!

 

 

Don't leave me hanging now. Any updates? 🙂 

Still waiting buddy. 🙂

/Patrik

Sorry my friend. Above observation is sent to IIS server team. They sent to MS for analysis. Once i grave update i will provide here. As of now its server side issue wt i understand.