Forum Discussion

Cirrus

Jan 24, 2020

F5 Server SSL Profile using TLS 1.0 instead of TLS 1.2

Hi I have an F5 virtual server that does SSL inspection so it has a client ssl profile and a server ssl profile. The backend server is running on a Windows Server 2019 / IIS and it only accepts...

pstavr
Jan 31, 2020
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.

pstavr

Cirrus

Jan 24, 2020

If you see the yellow-highlighted TLS version, that is F5 sending Client Hello. Its TLSv1. The exact same PCAP capture on Windows 10 clients accessing the Windows Server 2019 directly shows up TLSv1.2.

Rodrigo_Albuque
MVP
Jan 24, 2020
Which version of BIG-IP are you using?
- pstavr
  Cirrus
  Jan 24, 2020
  14.1.2.1
- Rodrigo_Albuque
  MVP
  Jan 24, 2020
  I'm not convinced this is the problem.
  
  Are you able to access IIS logs to see what it says about this handshake?
  
  It could be cipher mismatch, for example.
- pstavr
  Cirrus
  Jan 24, 2020
  We extracted a list of the ciphers supported from IIS. Quite a few were common with F5 so they were included in the Client Hello. Thats why I am saying I agree with you that it should accept one of them and proceed further by sending a Server Hello.
  I was thinking of creating a list of ciphers based on the extracted ones from IIS and create a custom cipher list to be 100% match for the one on IIS. But even if that would work, it still does not explain why a RST ACK is sent now when there are so many common ciphers between the two...