dsccommunity / SChannelDsc

MIT License
12 stars 6 forks source link

SChannelSettings: SchUseStrongCrypto not applied if .Net Framework 4.6 and higher is found. #9

Closed bdanse closed 4 years ago

bdanse commented 4 years ago

Details of the scenario you tried and the problem that is occurring

Due to an error in retrieving a module from the powershell gallery I stumbled upon an issue with regards to the SchannelSettings code. For example:

PS:\> Find-Module SChannelDSC
WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
PackageManagement\Find-Package : No match was found for the specified search criteria and module name 'SChannelDSC'.
Try Get-PSRepository to see all available registered module repositories.

And I am sure it is there. Checking Tls settings I found they where set to the default values.

PS:\> [Net.ServicePointManager]::SecurityProtocol
Ssl3, Tls

PS:\> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Explicite setting of protocol to tls12 restored the working of Find-Module.

Checking HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319 I found that SchUseStrongCrypto was not set. Even though we use SChannelSettings resource.

So to verify this was the issue is had set the keys SystemDefaultTlsVersions and SchUseStrongCrypto a new session to verify these settings and Find-Module works correctly without setting TLS via the ServerPointManager.

PS:\>  [Net.ServicePointManager]::SecurityProtocol
SystemDefault

Verbose logs showing the problem

PS:\> Invoke-DscResource -Name SChannelSettings -ModuleName SChannelDsc -Method Test -Property @{
 EnableFIPSAlgorithmPolicy = $False;
 TLS12State = "Enabled";
 IsSingleInstance = "Yes";
 DiffieHellmanMinClientKeySize = 2048;
 DiffieHellmanMinServerKeySize = 2048;
} -Verbose

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = ResourceTest,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer host with user sid.
VERBOSE: [host]: LCM:  [ Start  Test     ]  [[SChannelSettings]DirectResourceAccess]
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Testing SChannel configuration settings
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Getting SChannel configuration settings
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Getting TLS v1.2 state
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] .Net Framework 4.6 or higher used, TLS 1.2 state not applicable
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Getting Diffie Hellman Key Size
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Getting FIPS Algorithm Policy
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Current Values: DiffieHellmanMinClientKeySize=2048; DiffieHellmanMinServerKeySize=2048; EnableFIPSAlgorithmPolicy=False; IsSingleInstance=Yes; TLS12State=
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] Target Values: DiffieHellmanMinClientKeySize=2048; DiffieHellmanMinServerKeySize=2048; EnableFIPSAlgorithmPolicy=False; IsSingleInstance=Yes; TLS12State=Enabled; 
Verbose=True
VERBOSE: [host]:                            [[SChannelSettings]DirectResourceAccess] SChannel settings compliant.
VERBOSE: [host]: LCM:  [ End    Test     ]  [[SChannelSettings]DirectResourceAccess] True in 0.4260 seconds.
VERBOSE: [host]: LCM:  [ End    Set      ]    in  1.2910 seconds.
VERBOSE: Operation 'Invoke CimMethod' complete.

InDesiredState 
-------------- 
True           
VERBOSE: Time taken for configuration job to complete is 1.648 seconds

The log states ".Net Framework 4.6 or higher used, TLS 1.2 state not applicable". This may be the case for .net apps. Though when SchUseStrongCrypto and SystemDefaultTlsVersions are not set Powershell seems to switch to default "Ssl3, Tls"

And since the WMF 5.1 document states it needs .NET Framework 4.5 my assumption is it uses the "older" mechanism.

Suggested solution to the issue

Maybe removing the if statement and alway testing these setting would solve the issue as SChannelSettings will always Test and Set the values accordingly.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

See description

The operating system the target node is running

OsName : Microsoft Windows Server 2016 Datacenter OsOperatingSystemSKU : DatacenterServerEdition OsArchitecture : 64-bit WindowsBuildLabEx : 14393.3808.amd64fre.rs1_release.200707-2105 OsLanguage : en-US OsMuiLanguages : {en-US}

Version of Windows that is used (e.g. Windows Server 2016)

Windows Server 2016

Version and build of PowerShell the target node is running

Name Value


PSVersion 5.1.14393.3471 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.14393.3471 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1

Version of the DSC module that was used

1.1.0.0. Checked 1.2.0.0 it contains same code with regards to SchUseStrongCrypto and SystemDefaultTlsVersions

aydeisen commented 4 years ago

@bdanse Is .NET 3.5 installed on the machine you're testing from? I was only able to replicate your issue on a 2016 server that had both the .NET Framework 4.7+ and 3.5 features enabled

As documented, NET Framework 4.6.2 and later supports TLS 1.1 and TLS 1.2. Confirm the registry settings, but no additional changes are required..

While I could be missing it, when I look at the SChannelSettings Module, I'm not seeing any logic to take into account a server that has both a version of .NET higher than 4.6.2 as well as 3.5 installed.

If I'm understanding correctly, what this DSC resources should therefore be doing is adding the registry keys for .NET 3.5, even if it excludes the registry keys for .NET 4.6.2+

Assuming .NET 3.5 is enabled on the server you're referencing: if you manually add the registry keys for .NET 3.5 without the keys for .NET 4.6.2+, does the problem resolve?

ykuijs commented 4 years ago

@bdanse Did some testing myself and I am able to confirm the same behavior your are seeing. I agree that it would be best to remove the .Net check.

@aydeisen Good spot, currently if .Net 3.5 is installed next to .Net 4.6.2+ this code won't update the v3.5 settings. The above change will also fix this issue!

ykuijs commented 4 years ago

v1.2.1 has been released