search

AzureAD / microsoft-authentication-library-for-dotnet

Microsoft Authentication Library (MSAL) for .NET
https://aka.ms/msal-net
MIT License
1.38k stars 339 forks source link

Default to TLS 1.2 connections by compiling to supported .NET FW target (4.6.2 minimum) to avoid changing registry #3761

Closed NiklasEMS closed 1 year ago

NiklasEMS commented 1 year ago

Which version of MSAL.NET are you using? Microsoft.Identity.Client 4.36.0.0 (tested latest also later with same issue)

Platform .NET 4.8 on Windows 2019

What authentication flow has the issue?

Is this a new or existing app? Existing application starts to fail with Azure AD complaining it connects with TLS 1.0 or lower. There is new enforcement of TLS 1.2 now in Azure AD.

Expected behavior Microsoft.Identity.Client should be compiled with supported .NET FW target to automatically use TLS 1.2 without registry modification.

Actual behavior Microsoft.Identity.Client and other applications compiled with < .NET FW 4.6.2 , is not able to use TLS 1.2.

Possible solution Recompile Microsoft.Identity.Client with .NET 4.6.2 or later.

Additional context / logs / screenshots / links to code Also in general we only support .NET 4.6.2, 4.7.2, 4.8, 4.8.1 so best to compile with the minimum supported version instead of older unsupported also here: https://support.microsoft.com/en-us/topic/-net-framework-4-5-2-4-6-4-6-1-end-of-support-faq-72b7d8ca-3057-4f0c-8404-67305d40cc04 https://devblogs.microsoft.com/dotnet/net-framework-4-5-2-4-6-4-6-1-will-reach-end-of-support-on-april-26-2022/ ( .NET Framework 4.5.2, 4.6, 4.6.1 will reach End of Support on April 26, 2022 )

Workaround (manually add registry to force TLS 1.2): :: Admin cmd, check current settings, make a note of them if needed to revert back reg query HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /reg:32 reg query HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /reg:64

:: Add .NET SchUseStrongCrypto setting set to 1 for both 32-bit and 64-bit applications reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /f /reg:32 reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /f /reg:64

:: Add .NET SystemDefaultTlsVersions setting set to 1 for both 32-bit and 64-bit applications reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32 reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

:: Validate settings reg query HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /reg:32 reg query HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /reg:64

bgavrilMS commented 1 year ago

@jmprieur @rymeskar @gladjohn @crmann1 - would you have any objections to us bumping support from 4.6.1 (which is deprecated) to 4.6.2 (which is still supported) ?

gladjohn commented 1 year ago

@jmprieur @rymeskar @gladjohn @crmann1 - would you have any objections to us bumping support from 4.6.1 (which is deprecated) to 4.6.2 (which is still supported) ?

Adding lacomc for VS Feedback guidance, and edwardskrod for VS Installer.

rymeskar commented 1 year ago

No objection with bumping to 4.6.2.

bgavrilMS commented 1 year ago

@NiklasEMS - have you found any references that state that net462 behaves better for tls/

gladjohn commented 1 year ago

Transport Layer Security (TLS) best practices with the .NET Framework

bgavrilMS commented 1 year ago

2 issues:

  1. that article mentions net47 as minimum, not net462
  2. It states that the app needs to target a later version.

Afaik it should not matter what MSAL builds against. We build against the NET461 API surface. But the app defines the runtime. So if the app uses net48, all the APIs that MSAL is calling into will be net48 APIs.

For example, MSAL calls x509Certificate.Sign(byte[]) is super buggy on net461, but our customers do not run into problems because they run it on net472 or net48 where most bugs were fixed.

bgavrilMS commented 1 year ago

According to this SO post upgrading to net462 will not fix the issue, so we're going keep this as is.

NiklasEMS commented 1 year ago

Sorry for the confusion earlier regarding target. Since Windows 2016 moved out of mainstream support in January 2022, perhaps bumping up to .NET 4.7 is good to avoid this issue? Those few who are still using Windows 2016 should be able to upgrade from .NET 4.6.2 to .NET 4.7.2 or 4.8.x. Windows 10-1703 (retired support back in 2019) and later Windows versions have .NET 4.7 or higher pre-installed. (Windows 2019=Windows 10-1809)