*-PasswordStateResource: Remove forcing TLS 1.2
colombeen opened this issue · 9 comments
By forcing this it breaks other modules that we use.
Error we get in some other modules:
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.This should work:
PS C:\> [System.Net.ServicePointManager]::SecurityProtocol = @([System.Net.ServicePointManager]::SecurityProtocol, 'Tls12')But here we force Tls 1.2 on the server, so that you don't have to fix it in PS code
The reason for adding this is that by default Powershell uses TLS 1.0 for invoke-webrequest or invoke-restmethod. It works for servers that have TLS 1.0 and TLS 1.2 Enabled but not those with just TLS 1.2.
https://blog.pauby.com/post/force-powershell-to-use-tls-1-2/
I'll see if the method you suggested also works and adopt that if not i can get it to set back to defaults afterwards as fix.
Actually the method you suggested just appends TLS 1.2 which isn't quite the same, my method is to only use TLS 1.2 as the others are insecure. I'll get it to set back to defaults after but i'd rather use TLS 1.2 only.
I am using this on the iis server to force tls 1.1/1.2 : https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
Forcing this on the client is not recommended, as an attacker would, leave this enforcement out and bring the lesser secure ones in, and/or wouldn't use this module at all.
I am using this on the iis server to force tls 1.1/1.2 : https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
Forcing this on the client is not recommended, as an attacker would, leave this enforcement out and bring the lesser secure ones in, and/or wouldn't use this module at all.
The server is set to TLS 1.2 only. The issue is powershell not using TLS 1.2 by default so the connection fails where the server doesn't have TLS 1.0 also enabled.
Modules shouldn't force a specific session or systemwide session which could potentially break other code. Even though TLS1.2 is recommended, this might break code for less secure connections (which might be required for legacy purposes).
So you should either revert the setting to what it was after your call, add Tls1.2 to the existing protocols, or maybe warn the user about insecure protocols being enabled in the session.
Merging the fix, it's essentially what i was going to do.
I've been testing this issue, it appears that powershell follows the .net strong encryption.
As taken from:
https://powershell.org/forums/topic/is-it-possible-to-enable-tls-1-2-as-default-in-powershell/
Set registry key:
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
This registry setting worked for me. I had to close PowerShell session and open a new one.
PS > [Net.ServicePointManager]::SecurityProtocol
Tls, Tls11, Tls12
In our environment we run the powershell script on all servers and clients: https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12
So that would explain, this isn't needed.
@dnewsholme can you test if using the SchUseStrongCrypto, without setting it in powershell?
The reg key does work, however setting via the [Net.ServicePointManager]::SecurityProtocol ensures it always works regardless of peoples registry keys, which is a better user experience imo. The setting is only changed for the duration of the command and then reverted again so shouldn't present issues.
Is this causing issues for you on a fixed build?