Dnn.platform: RFC: Support TLS 1.2, 1.1 and 1.0 with a fallback plan to avoid a breaking change

[david-poindexter]

Description of Problem

Currently, if DNN is installed on a host that only has TLS 1.2 enabled, and it is making calls to APIs that require TLS 1.2, those calls will fail. @davidjrh created a GitHub project to force TLS 1.2 on DNN instances by dropping a DLL in the bin folder. However, I would think we need to implement a fallback feature to support TLS 1.2/1.1/1.0 explicitly in DNN.

Proposed Solution Option 1

Implement the following code:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

This will try to use TLS 1.2 first and if it is not possible, TLS 1.1, etc.

Considerations

It is not apparent to me where this code should reside within the core. Ideas and comments are welcome. I'll be happy to submit a pull request once it is determined the proper place for this to live.

Affected version

• [x] 9.3.0
• [x] 9.2.2
• [x] 9.2.1
• [x] 9.2
• [x] 9.1.1
• [x] 9.1
• [x] 9.0

[daguiler]

I've been reading a bit about this and the recommendation is not to hard code the supported protocols and instead upgrade to latest .NET framework versions where this issue is better handled.

A paragraph from MS:

We recommend that you:

• Target .NET Framework 4.7 or later versions on your apps. Target .NET Framework 4.7.1 or later versions on your WCF apps.
• Do not specify the TLS version. Configure your code to let the OS decide on the TLS version.
• Perform a thorough code audit to verify you're not specifying a TLS or SSL version.

When your app lets the OS choose the TLS version:

• It automatically takes advantage of new protocols added in the future, such as TLS 1.3.
• The OS blocks protocols that are discovered not to be secure.

[mitchelsellers]

@nvisionative I agree with @daguiler this should be resolved when we upgrade to 4.7.2 which is planned for DNN 9.4.0

[david-poindexter]

Sounds great guys! I'll go ahead and close this one.

[sleupold]

this might be combined with support for http/2 (#2587)