- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
Many PowerShell blogs like to mention that WinRM encrypts data and is therefore secure even if you only work with HTTP (which is the default configuration) and not with HTTPS. Indeed, Microsoft’s documentation for Invoke-Command confirms that WS-Management encrypts all transmitted PowerShell data. (An older version of WinRM on Windows Server 2003 R2 doesn’t encrypt.) Unfortunately, if not configured properly, PowerShell Remoting is insecure and it some cases you need to change the default configuration.
Allowing unencrypted PowerShell Remoting ^
First, it is possible to allow unencrypted WS-Management communication. This command configures the WinRM service to allow unencrypted traffic (you need an elevated console as for most things we do in this post):
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
Allowing unencrypted WSMan traffic on the server
And this one does the same on the client side:
winrm set winrm/config/client '@{AllowUnencrypted="true"}'
Even though WS-Management encrypts all traffic by default, it is possible that someone (unknowingly) transmits unencrypted data because the default configuration has been changed. I guess this is why this Microsoft article about WinRM warns that “under no circumstances should unencrypted HTTP requests be sent through proxy servers.”
Allowing unencrypted WSMan traffic on the client
To check how your machines are configured, you can run this command:
winrm get winrm/config
Checking WinRM configuration
You can also view the configuration in PowerShell:
dir WSMan:\localhost\Service | ? Name -eq AllowUnencrypted dir WSMan:\localhost\Client | ? Name -eq AllowUnencrypted
Why HTTPS with Invoke-Command and Enter-PSSession ^
The second and, in my view, bigger problem is that, if you are working with machines that are not in an Active Directory domain, you don’t have any trust relationship with the remote computers. You are then dealing only with symmetric encryption, so man-in-the-middle attacks are theoretically possible because the key has to be transferred first.