2

I need to connect to a webservice that uses TLS1.3.

It seems when I use ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13 it does not connect giving me the exception:

"The client and server cannot communicate, because they do not possess a common algorithm"

The project is using .NET 4.8 and I have tried running the software on both Windows 10, and windows server 2016. in both cases using Wireshark I don't even see an attempt by the client to list valid ciphers it can use.

Any insight into this issue would be appreciated.

Mohsen Esmailpour
  • 11,224
  • 3
  • 45
  • 66
leggolos Denrif
  • 23
  • 4
  • 1
    Hard-coding the TLS version won't make the client machine suddenly support TLS1.3. It *will* prevent the application from trying other supported versions – Panagiotis Kanavos Feb 18 '22 at 15:36
  • 1
    So... what you are telling me is that Even though .NET 4.8 states that is supports TLS1.3 because it uses SChannel of Windows to do its work and according to this table here https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp- Windows 10 does Not support TLS1.3 natively and I am screwed? – leggolos Denrif Feb 19 '22 at 16:17
  • I'm telling you that .NET Framework 4.8 works as advertised and clearly explained since 2016: it uses the best available algorithm provided by the operating system and *the remote server*. If you hard-code a value, you're *restricting* the available algorithms and *preventing* your application from using newer algorithms. You can enable or disable algorithms at the OS level if you apply the proper patch. As the page you linked to shows though, TLS1.3 is enabled by default starting with Windows 11. Which is a free upgrade in most cases. And a semi-required upgrade in the Windoes-as-Service era – Panagiotis Kanavos Feb 21 '22 at 07:21
  • 1
    BTW you aren't screwed. Just don't arbitrarily require a specific algorithm. TLS 1.2 isn't broken. Do you have a *real, actual need* for TLS 1.3? Or did someone decide to just use the best current algorithm "because security"? What happens when people start moving to TLS 1.4? Or using more secure algorithms and larger keys *within* TLS 1.3? You can enable such features through registry keys, OS patches or feature switches without having to redeploy your application – Panagiotis Kanavos Feb 21 '22 at 07:22
  • Why is the project using old versions like Windows Server 2016 and .NET Framework in 2022, but requiring the latest TLS protocol? What are the *actual* requirements and restrictions? If you really need to use TLS 1.3 on the server side, a far better option would be to use .NET 6 to begin with. This would allow you to use HTTP/2 out of the box *and deploy to a Linux VM, Container or even WSL* if you can't use Windows Server 2022. – Panagiotis Kanavos Feb 21 '22 at 07:40
  • It is older software that has been in use for years, and the server that it connects to is not controlled by us, they are updating their server to TLS1.3 and we have no option there. We can't upgrade to a newer version of windows very easily as that would require a lot of money(more than one server with applications that need to be updated) and changing the software to .NET 6 may require extensive write, which we are attempting to avoid. will .NET 6 support TLS1.3 even if the OS doesn't? is there a way to enable or add TLS1.3 support to the OS so that .NET 4.8 can use it? – leggolos Denrif Feb 23 '22 at 16:08

0 Answers0