PowerShell Gallery TLS Support
Sydney Smith
Summary
To provide the best-in-class encryption to our customers, the PowerShell Gallery has deprecated Transport Layer Security (TLS) versions 1.0 and 1.1 as of April 2020.
The Microsoft TLS 1.0 implementation has no known security vulnerabilities. But because of the potential for future protocol downgrade attacks and other TLS vulnerabilities, we are discontinuing support for TLS 1.0 and 1.1 in the PowerShell Gallery.
For information about how to remove TLS 1.0 and 1.1 dependencies, see the whitepaper Solving the TLS 1.0 problem.
More information
As of April 2020, TLS 1.2 is set to be the default for the PowerShell Gallery.
Please note that TLS 1.0 and 1.1 was already unsupported, but the actual deprecation when PowerShell Gallery will now stop accepting any connections using TLS 1.0 and 1.1 has occurred.
We recommend that all client-server combinations use TLS 1.2 (or a later version) to maintain connection to the PowerShell Gallery.
Mitigation
To mitigate this chance we have released a minor update to PowerShellGet which will allow you to continue to interact with the PowerShell Gallery. To install this run:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Install-Module PowerShellGet -RequiredVersion 2.2.4 -SkipPublisherCheck
Note:
This in this version of PowerShellGet when a call is made to the PowerShell Gallery, PowerShellGet will save the user’s current security protocol setting, then it it’ll change the security protocol to TLS 1.2 (by specifying [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12), after the action is taken by the cmdlet it will change the user’s security protocol back to what it was before the cmdlet was run.
Errors I Might See
If you are running an older version of TLS and try to interact with the PowerShell Gallery you may see error messages like:
Publishing
+ ... Publish-PSArtifactUtility @PublishPSArtifactUtility_Param ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : FailedToCreateCompressedModule,Publish-PSArtifactUtility
Installing
+ ... $null = PackageManagement\Install-Package @PSBoundParameters + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (C:\Users\T-Ncho...anagement.nupkg:String) [Install-Package], Exception + FullyQualifiedErrorId : PackageFailedInstallOrDownload,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
Concerns and Support
Please open an issue in our GitHub repository or contact our gallery support channel through cgadmin@microsoft.com if you have any concerns, challenges, or are unable to upgrade to TLS 1.2 or above.
Sydney Smith
PowerShell Team
Light
Dark
3 comments
I suggest to add `Tls12` rather than change other existing and already enabled protocols via:
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
Also, just opening any PowerShell Console and running the command does not do the trick because it won’t persist. This issue only affects older operating systems and/or users of Windows PowerShell
Could this be resolved with an updated PackageManagement or PowerShellGet module?
Otherwise this seems a pretty impactful change with a lot of ripples.
The fix is really simple
HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319
HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319
KeyName – ‘SchUseStrongCrypto’
Value – Dword:00000001
This be done with the following PowerShell command:
# Set strong cryptography on 64-bit .NET Framework (version 4 and above)
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord
# Set strong cryptography on 32-bit .NET Framework (version 4 and above)
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord