Forum Discussion
CirrusF5 Server SSL Profile using TLS 1.0 instead of TLS 1.2
Hi all.
I found the root cause. The problem was related to the .NET app using SNI. By default the F5 doesn't do that.
https://devcentral.f5.com/s/articles/ssl-profiles-part-7-server-name-indication
So basically I just followed the fix in the above article, I defined a server name and the backend service started sending Server Hello etc. Everything works fine now!
Thank you all for your responses, as quite a few of them were helpful on identifying that the issue is with the app, and I could also spot a few things that were not proper on the negotiation part.
CirrusHi Rodrigo
Thank you for your reply. We are already trying a few tweaks on the Windows Server 2019 / IIS environment for fixing this. I understand your comment and it makes sense. What I do not understand however is why would F5 use TLS 1.0 initially to contact the backend server during the Client Hello. I am using a server SSL profile which limits the ciphers to TLS 1.2 only. I should also mention that Windows 10 clients accessing the backend server directly work perfectly fine. While doing a Wireshark capture on the Windows Clients, the Client Hello is entirely on TLS 1.2 (both lowest and highest version). Hence my questioning on why F5 would send a TLS 1.0 Client Hello. The packet is marked as TLS1 on Wireshark.
Cirrocumuluspstavr,
That is what I'm trying to explain.
The TLS1.0 Client Hello BIG-IP is sending is just a convention to signal which version it supports.
If your Windows client only sends TLS1.2/TLS1.2 it means it only supports TLS1.2 and nothing else.
Because BIG-IP supports TLS1.0, TLS1.1 and TLS1.2 it signals to server TLS1.0/TLS1.2.
This is expected behaviour.
And FYI, I took a capture on my Ubuntu box and this is my client hello:
Does it make sense?
- pstavr
Sort of does. I guess I would say it makes sense if you use DEFAULT on the ciphers. But if you restrict it to TLS 1.2, why would the F5 send TLS 1.0 as the lowest? I do 100% agree though that there is something wrong with the backend server so we need to tweak it to be more "open", at least during the negotiation process.
- Rodrigo_Albuque
If you're restricting BIG-IP to ONLY TLS1.2 then that might be a bug as BIG-IP is supposed to send TLS1.2/TLS1.2 in my understanding. However, the fact that BIG-IP signals IIS that it supports TLS1.0 to TLS1.2 is not supposed to trigger connection failure. The fact that BIG-IP also supports TLS1.0 and TLS1.1 is not supposed to break the connection. IIS is supposed to reply with TLS1.2 version and keep going. I'd say this is a broken behaviour from IIS and I believe the easiest thing to solve your issue is just to have a quick look at IIS log when the connection fails. Other than that, you can definitely open a low-priority (Sev4) Support ticket with F5 and ask them to file a low-priority bug for this behaviour.
Simon_BlakelyEmployee
> But if you restrict it to TLS 1.2, why would the F5 send TLS 1.0 as the lowest?
Late to the party, but you might appreciate this explanation:
F5 SSL profiles distinguish between Ciphers and Protocols.
Your cipher string restricts the cipher list to only those ciphers that are supported on TLSv1.2, but the server-ssl profile still supports the TLS Protocols from TLSv1 - TLSv1.2.
You can only negotiate TLSv1.2 ciphers on the TLSv1.2 Protocol, but you haven't explicitly instructed the profile to disable the earlier TLS Protocols, so it offers them.
You can disable TLS Protocols using the Options settings (No TLSv1, No TLSv1.1 ).
I hope this provides some useful information.
