Docs: Not getting default values on .NET 4.7.2 on Windows 10 (1709)

[singhmss]

I am running a console application targeting .NET 4.7.2 on Windows 10 (1709, OS Build 16299.755). When I checked the ServicePointManager.SecurityProtocol it had the value 'Ssl3, Tls' instead of SecurityProtocolType.SystemDefault as indicated in the section 'For HTTP networking' (#for-http-networking). When I used HttpClient to send a request to a server only accepting TLS 1.2 I got an exception, System.Net.WebException stating that an SSL/TLS secure channel could not be created. Could you please explain why the SystemDefault value was not used?

The section Switch.System.Net.DontEnableSystemDefaultTlsVersions states that "If your app targets .NET Framework 4.7 or later versions, this switch defaults to false." However I had to explicitly set the value of this switch to false. After this the ServicePointManager.SecurityProtocol had the value SystemDefault and the HttpClient was able to send a request over TLS 1.2. Similarly the section on Switch.System.Net.DontEnableSchUseStrongCrypto states that this switch defaults to false if the app targets .NET Framework 4.6 or later versions. After I explicitly set this switch to false the ServicePointManager.SecurityProtocol had the value 'Tls, Tls11, Tls12' and HttpClient was able to send the request over TLS 1.2.

Likewise the sections for the corresponding registry keys state that the keys should default to 1 for my case however I had to set them explicitly to get the behaviour described above. Could you please explain why the switches or registry keys had to be set explicitly for my application to use TLS 1.2?

The 'Security Updates' section states that "To update the .NET Framework to allow the operating system to choose the best version of TLS to use, you must install at least:...". The page for '.NET Framework September 2017 Security and Quality Rollup', does not provide a download for Windows 10 (1709). It offers a download KB4038788 (OS Build 15063.608) for Windows 10 1703. The build number of my OS is higher, 16299.755. Does this mean that my OS would already have this update?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7341fa0a-f474-6c2d-d3c0-7e2df12fbb65
• Version Independent ID: e99c489a-7518-d293-ad93-7eaca8b7191a
• Content: Transport Layer Security (TLS) best practices with the .NET Framework
• Content Source: docs/framework/network-programming/tls.md
• Product: dotnet-framework
• Technology: dotnet-networking
• GitHub Login: @karelz
• Microsoft Alias: ncldev

[karelz]

Check your sample, try a minimal test like here: https://github.com/microsoft/dotnet/issues/1138#issuecomment-589779845

[singhmss]

@karelz I am testing with a simple application similar to your sample. I was debugging it on VS2015 and this point was discussed in the issue #microsoft/dotnet#1138 . When I run the application directly from command line I get SystemDefault as expected. Also I debugged the same application on VS2017 and I got SystemDefault as expected.

So it indeed seems that when debugging on VS2015 ServicePointManager.SecurityProtocol defaults to 'Ssl3, Tls' even though the application targets .NET 4.7.2. Thank you for your help.

I had another question regarding the update to support SystemDefault behaviour on Windows 10 or Windows Server 2016. The best practices article mentions installing at least '.NET Framework September 2017 Security and Quality Rollup.' and the page for that update provides KB4038788 with OS Build 15063.608 which is lower than my current OS Build 16299.755. So in general if my OS build is higher than the one mentioned with an update would that mean my OS already supports the behaviour provided by the update?

[karelz]

Great, culprit has been identified -- VS 2015 debugger targeting older version of .NET Framework. We close this issue.

Regarding your next question - I don't have expertise in comparing versions. I would make sure you have Security and Quality Rollup installed which is older than September 2017. The page also lists How to: Determine Which .NET Framework Versions Are Installed as source of further into.

[karelz]

@BillWagner who can help us get this issue closed?
Is there a reason why members of runtime team who have content in docs don't have RW permissions to docs repo?

[BillWagner]

@karelz

Is there a reason why members of runtime team who have content in docs don't have RW permissions to docs repo?

That's easy to fix. The dotnet-corefx team has write access to dotnet/dotnet-api-docs. Should I give permissions to the same team, or is there a more appropriate team to add?

[karelz]

@BillWagner same team please, thanks!

[BillWagner]

@karelz Done.