Dotnet: The Windows 10 .Net 4.8 Oct update removes TLS 1.1, 1.2. 1.3 from default security protocols from .Net apps forcing traffic to use SSL3 and TLS 1.0.

[baschlegel]

These are the updates to the Windows 10 versions that downgrade the security protocols.
Win 10 1803, KB4519572
Win 10 1809, KB4519565
Win 10 1903, KB4519573

Before applying the updates the default security protocols have this value:
System.Net.ServicePointManager.SecurityProtocol: Tls, Tls11, Tls12, Tls13

After the updates are applied to the Windows 10 pc's this is the default value for the security protocol:
System.Net.ServicePointManager.SecurityProtocol: Ssl3, Tls

Our application was using .net 4.6. I tried updating our app to .net 4.6.2, 4.7.2, and 4.8 and none of those versions fixed the issue.

[pete-bloomerang]

We seem to have discovered the exact same issue, but I can't help but notice that there aren't any comments here and this ought to be a gigantic problem if widespread. Are there any updates to this or any additional information about this issue?

[baschlegel]

No updates at all. I ended up having to check the default protocols before
calling my web services and if TLS 1.1 and TLS 1.2 are missing then I have
to manually include them. This seems like a huge bug in the .NET Framework.

On Fri, Feb 21, 2020 at 8:54 AM pete-bloomerang [e-mail]
wrote:

We seem to have discovered the exact same issue, but I can't help but
notice that there aren't any comments here and this ought to be a gigantic
problem if widespread. Are there any updates to this or any additional
information about this issue?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/dotnet/issues/1138?email_source=notifications&email_token=AGWBPX6CONR2LGD2XY5J4XDRD7TKTA5CNFSM4JKYCKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMS6TQY#issuecomment-589687235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGWBPX2GHIDQ4LHAWRNQU53RD7TKTANCNFSM4JKYCKHQ
.

[pete-bloomerang]

Thanks; we'll do the same. If we find anything else out I'll post an update here.

[nakarnam]

cc @karelz

[karelz]

This is a surprising report. I would not expect anything like this happening. Given the limited number of people reporting it, I assume it is not something widespread, but rather something interfering in the apps ... let's find out.

@baschlegel @pete-bloomerang can you please post your exact versions of Windows and of Cumulative update for .NET Framework you have installed on machines that show these symptoms? (@baschlegel listed 3 versions with KBs and I haven't seen any version info from @pete-bloomerang)

Can you try a simple HelloWorld app on those "buggy" machines?
Here's what I tried:
```c#
class Program {
static void Main() => System.Console.WriteLine(System.Net.ServicePointManager.SecurityProtocol);
}

**Targeting** 4.6 (App.config):
```xml
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />
    </startup>
</configuration>

Output on Win10 version 1909 (client OS) with latest KB 4534132 (Feb 11 Cumulative Update for .NET Framework), targeting .NET Framework 4.6:

Tls, Tls11, Tls12, Tls13

I am curious if this HelloWorld will have different output in your environments.

Also note, that once you target 4.7.1+, the result is different:

Targeting 4.7.1 (App.config):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.1"/>
    </startup>
</configuration>

Output on Win10 version 1909 (client OS) with latest KB 4534132 (Feb 11 Cumulative Update for .NET Framework), targeting .NET Framework 4.7.1:

[karelz]

And here's result, when your application targets 4.5 (while running on newer version of .NET Framework):

Targeting 4.5 (App.config):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
    </startup>
</configuration>

Output on Win10 version 1909 (client OS) with latest KB 4534132 (Feb 11 Cumulative Update for .NET Framework), targeting .NET Framework 4.5:

Ssl3, Tls

[karelz]

Looking at TLS best practices, I have a suspicion that this is what might have happened:

1. Your app targets .NET 4.5.2 or earlier
2. You don't have necessary registry keys set (see registry key settings for targeting .NET 3.5-4.5.2)
   
   
   
   • Wild guess: One of the OS updates may have nuked these registry keys from your registry (I think we have had such case in the past ... I have to check older emails)
   
   

[pete-bloomerang]

I'm able to reproduce all three outputs exactly on one of the machines with your code. I'll check the other machine too.

One of the services having the issue is targeting 4.7.2 (matching that in the app.config). I'll check registry values and windows updates and provide an update.

[pete-bloomerang]

I do have 4534132 installed as the latest .NET update (followed by a cumulative update for Windows 10: kb4532693)

[karelz]

If you are able to reproduce the same (correct) output on my minimal repro on machines where your real app has troubles suddenly after updates, then one of these things is possible:

• Either your app targets something different than you think (please double check app.config) and the reg keys for <4.5.2 are not set, or
• Something in your app sets the SecurityProtocol explicitly (maybe a library, maybe based on some version detection?)

I can't come up with different explanations ...

[baschlegel]

Unfortunately all of my test machines have had Windows updates applied
since I posted this issue and I'm not longer able to replicate the original
problem. When I first post the issue I had code similar to yours and it
would return System.Net.ServicePointManager.SecurityProtocol: Tls, Tls11,
Tls12, Tls13 before the security updates were applied. After the update
the code would only return
System.Net.ServicePointManager.SecurityProtocol: Ssl3, Tls. Your nuked
registry idea is possible. This is an older app that started out as .NET
3.5 and has be migrated up to .NET 4.6.2 over the years.

On Fri, Feb 21, 2020 at 1:01 PM Karel Zikmund [e-mail]
wrote:

If you are able to reproduce the same (correct) output on my minimal repro
on machines where your real app has troubles suddenly after updates, then
one of these things is possible:

• Either your app targets something different than you think (please
  double check app.config) and the reg keys for <4.5.2 are not set, or
• Something in your app sets the SecurityProtocol explicitly (maybe a
  library, maybe based on some version detection?)

I can't come up with different explanations ...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/dotnet/issues/1138?email_source=notifications&email_token=AGWBPX4JGO7T72O6J6CBRHTREAQIZA5CNFSM4JKYCKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMTXTCA#issuecomment-589789576,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGWBPX3ZBZK7UVMMYJEBJCDREAQIZANCNFSM4JKYCKHQ
.

[pete-bloomerang]

I believe HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319 is the correct location? I have no SchUseStrongCrypto or SystemDefaultTlsVersions entries set there. I actually don't have those set in any of the versions under .NETFramework.

[karelz]

Or one more idea: You have the reg keys SchUseStrongCrypto and/or SystemDefaultTlsVersions set to value 0 ... that will override behavior even if targeting 4.7.2

Output on Win10 version 1909 (client OS) with latest KB 4534132 (Feb 11 Cumulative Update for .NET Framework), targeting .NET Framework 4.7.2 with reg keys SchUseStrongCrypto and SystemDefaultTlsVersions set to 0:

Ssl3, Tls

[karelz]

Reg key paths for .NET Framework 4.x are:

• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

[karelz]

@pete-bloomerang let me know if you want to use more interactive troubleshooting channel ... I am curious what is happening on your machines.
gitter IM / Teams / Skype / Twitter DM - see my email in my profile.

[pete-bloomerang]

Reg key paths for .NET Framework 4.x are:

• HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319
• HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319

I do not have either SchUseStrongCrypto or SystemDefaultTlsVersions in either of those locations (assuming that the slash keeps getting dropped between Microsoft and .NETFramework).

To be clear, those keys should exist?

[pete-bloomerang]

I'm curious too. I've seen it locally while debugging and can reproduce it consistently through at least one particular code path. Let me re-read our conversation so far and take a look at the other server this may be occurring on to make sure it looks like the exact same thing. I'll reach out and let you know how that goes.

[karelz]

I do not have either SchUseStrongCrypto or SystemDefaultTlsVersions in either of those locations (assuming that the slash keeps getting dropped between Microsoft and .NETFramework).

Yes, sorry, the slash was dropped - fixed above.

To be clear, those keys should exist?

They have to exist IF you target 4.5.2 or lower. Otherwise NOT having them is ok.

[pete-bloomerang]

@karelz:

Turns out the debugger (VS 2015) seems to be forcing SecurityProtocol to "Ssl, Tls". When I run the apps from the command line directly, they all produce SystemDefault--when I debug them, they all show "Ssl, Tls". So now I'm not at all sure if there's even an issue (except that it would be nice to have SystemDefault even when debugging, but I read something indicating that was fixed for VS 2017 at some point).

If I do determine that there is still some weirdness here, I'll reach out to you via email.

Thanks for all of your help!

[karelz]

Oh, VS 2015 is ancient ... I bet it has its own config, targets older version of .NET Framework (<=4.5.2) and therefore you have to set the reg keys I linked above to 1.
Can you try to set the reg keys above to 1 and confirm it works?

Should I take it as confirmation that your original problem was only under debugger? That you did NOT see TLS downgrade in production of your services?

[pete-bloomerang]

@karelz I set the registry keys as described and both the console app and our own application now show "SystemDefault" while debugging, so you're right; those values need to be set for VS 2015--great call!

We had a report of a TLS issue in a production service (and have seen a spike in "Could not create SSL/TLS secure channel." messages while communicating with a third party's API since late last year). Unfortunately, the VS 2015 confusion caused us to believe we were able to consistently reproduce the production TLS issue. So Friday was a bit of a wash for us, I'm afraid, and it looks like we're back to square one on the original production issue.

[karelz]

@pete-bloomerang glad you identified at least part of the problem (on dev machines under debugger).
Let me know once you find more about your production issue ...

[karelz]

Looks like not enough info to troubleshoot. Closing.
If there is evidence pointing to weird unexpected behavior, feel free to reopen.