.NET v4.7 不存在 TLS1.2

Question

I'm getting an unhandled exception that says The request was aborted: could not create SSL/TLS secure channel so I'm trying to use Tls1.2 in hopes that it will fix this problem.

I read that the default for .NET versions 4.6 and above is TLS1.2

I have version 4.7 and have the line ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; in my code but there's a red linder under .Tls12 . Visual Studio says SecurityProtocolTypes does not contain a definition for Tls12 and recommends that I replace .Tls12 with .Tls

How can I use Tls1.2 in my code?

I should add that I've also tried: ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; and ServicePointManager.SecurityProtocol = (SecurityProtocolType)(0xc0|0x300 0xc00);

Answer 1

Did you read Transport Layer Security (TLS) best practices with the .NET Framework ?

It says:

To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded.

.NET Framework applications should use the TLS version the operating system (OS) supports.

And later:

If your app targets .NET Framework 4.7 or later versions

The following sections show how to verify you're not using a specific TLS or SSL version.

For HTTP networking

ServicePointManager, using .NET Framework 4.7 and later versions, defaults to the OS choosing the best security protocol and version. To get the default OS best choice, if possible, don't set a value for the SecurityProtocol property. Otherwise, set it to SystemDefault.

So if it does not work by default... maybe you are not really using 4.7?

Or maybe your operating system is so old it does not support it?

Or maybe the target does not support it?

Either way, there should be no need to explicitly set it to 1.2

Answer 2

@nvoigt answered the question correctly but I thought I would share my recent experience with this seeing that its very similar, but with a twist.

Backstory: I have an application that was developed targeting .net 3.5 and was built using Visual Studio 2013, Update 1. This was for compatibility for another application. In that application, it consumed an endpoint that was updated to use TLS 1.2. Because .net 3.5 does not support TLS 1.2, we had to address this issue.

Based on the answer that @nvoigt posted (and the rest of the web for that matter) I understood that upgrading the application to target a newer .net framework (4.7.1 in my case) would resolve the problem as long as we were not hard-coding any of these protocols in our application. This would allow the OS to indicate the protocol.

Problem: Using Visual Studio 2013, Update 1 - I updated the target framework of our app to .net 4.7.1 and verified that the ServicePointManager.SecurityProtocol was not being hard-coded anywhere so it would defer to the OS. This did not work , no matter how many articles I read on the web saying that it would.

Resolution: Using Visual Studio 2019 - I opened and tested the exact same app that was still targeting .net 4.7.1 with no other changes besides the version of Visual Studio used to compile the project. This DID work!

My Findings: I wanted to eliminate any chance that there was something else in my specific project that may have been causing this issue. To do this I created a brand new windows forms project and in the static void Main() method of the Program class I set the following variable var x = ServicePointManager.SecurityProtocol; to see what value was being set by default. This was the ONLY modification that I made to the new project. I then continued to debug the EXACT SAME NEW PROJECT in both Visual Studio 2013 and Visual Studio 2019 (both still targeting .net 4.7.1) and I got the results shown below:

Visual Studio 2013 - (targeting .net 4.7.1)

var x = ServicePointManager.SecurityProtocol;
//  ^ x defaults to 'Ssl3 | Tls'

Visual Studio 2019 - (targeting .net 4.7.1)

var x = ServicePointManager.SecurityProtocol;
//  ^ x defaults to 'SystemDefault'

See the below side-by-side screenshot (VS 2013 on the Left, VS 2019 on the Right):

Even if I manually set ServicePointManager.SecurityProtocol = SecurityProtocolType.SystemDefault; in Visual Studio 2013 it would just not work! The only way to make it work in Visual Studio 2013 was to hard-code the protocol like this ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; which we all know is not a best practice.

Lesson learned: When nothing else seems to work when you know it should, test by compiling your application using a newer version of Visual Studio or make sure the version you're using has the latest updates applied.