Don't manually change the TLS version using ServicePointManager.SecurityProtocol

Posted on January 10, 2023

Coming late to the game, but I've often saw, in the TLS 1.0 & 1.1 deprecation era, people disabling these protocols by simply doing the following:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12

Sure, it will work, but this line of code is far from ideal and is not friendly maintainability wise. Reasons around that:

  • You might have to write this line of code in a couple of different areas of your code
  • You will have to keep track of those areas for future updates (e.g., for the deprecation of TLS 1.2 by example)
  • It's not guaranteed third party libraries will work with the instruction

Microsoft recommends to do otherwise and I'll admit it's quite simpler this way than the other around. All in all, what you need inside your app configuration is the following:

<appSettings>
    <add key="AppContext.SetSwitch:Switch.System.Net.DontEnableSchUseStrongCrypto" value="false" />
    <add key="AppContext.SetSwitch:Switch.System.Net.DontEnableSystemDefaultTlsVersions" value="false" />
</appSettings>

This instructs your app to use the system recommended cyphers and TLS versions when your app is doing secure communications. So, without changing a single line of code, you're asking .NET to follow the system recommendations, not his.

Keep in mind, per the documentation of Microsoft, these settings will have an impact on certain .NET Fx targets:

  • For DontEnableSchUseStrongCrypto, applications compiled using a target framework lower than 4.6 are impacted
  • For DontEnableSystemDefaultTlsVersions, targets lower than .NET 4.7 are impacted

Otherwise, by default, these configurations are disabled. This means they use the recommended TLS version and strong cryptos.

Another thing to point out, certain third-party libraries, compiled using old .NET targets will also be impacted. Say, by example, you have added a NuGet package targeting only .NET 4.5, well these settings are also impacting your reference. If by any way it's using TLS, the library will also use the system recommended versions. By experience, this also applies even though your app is compiled using a recent .NET target (e.g., 4.7.2). So, if you're not specifying the flags and that you're referencing a third-party library compiled with an older target, you should also specify the flags, as the library otherwise will fallback in using the wrong TLS version and cyphers.