Powershell: Support changing cipher suites offered by Invoke-WebRequest and Invoke-RestMethod

[alx9r]

Invoke-WebRequest and Invoke-RestMethod are rather permissive compared to web browsers with respect to how the SSL/TLS connection is established. #4899 would provide support for user-defined certificate validation in Invoke-WebRequest and Invoke-RestMethod. That is an improvement but only affects part of the permissiveness. Another part is the cipher suites.

The cipher suites offered by Invoke-WebRequest and Invoke-RestMethod seem to be determined by system-wide registry key changes. The discussion in dotnet/corefx#21577 includes one example of why such a system-wide setting is problematic. Basically it means that in practice all .Net things on a single computer end up offering all cipher suites needed by any .Net thing that needs to run on that computer.
The net result is lowest common denominator security with respect to cipher suites. dotnet/corefx#21577 would make the cipher suites configurable per connection. Once that is implemented, it would be great for that configurability to be exposed by Invoke-WebRequest and Invoke-RestMethod.

[markekraus]

This is a dupe of #2662

[alx9r]

@markekraus This doesn't seem like a duplicate of #2662 to me. #2662 seems to be about restricting SSL/TLS _protocols_ and _protocol versions_. This issue is about restricting the _cipher suites_ offered during SSL/TLS negotiation. These are two different, but related aspects. (This page shows, for example, the cipher suites that _could_ be enabled on a Windows 10 computer for each version of TLS.)

It seems to me that in order for it to be possible for PowerShell automation using https to remain up-to-date with current policy (e.g. keep up with browsers) we need control over (at least) the following on a per-call basis:

1. Certificate Validation (#4899)
2. Permitted Protocols and Versions (#2662)
3. Permitted Cipher Suites (this issue #5159)

[markekraus]

Ah ok.

The problem being, this is currently not possible in CoreFX and from the threads you linked it's not even on the roadmap (yet), its all theoretical at this point, yes? We can't add the feature in PowerShell core until it is available in CoreFX and it's not clear that it will be available or not.

I agree this would be a nice to have feature but it can't be implemented at this time. If it were clear this was being added in CoreFX I would reopen this issue. @alx9r let's watch those CoreFX issues and if they reach a point where it will be implemented we can either open a new issue or re-open this one.

[alx9r]

Got it. Thanks @markekraus.

[petemounce]

I would find it really useful to be able to specify cipher suites. I have automation that hits github via PowerShell invoke-webrequest that stopped working yesterday.

Googling picked up that github have disabled some weak cipher suites on 22/February: https://githubengineering.com/crypto-removal-notice/

[alx9r]

I agree this would be a nice to have feature but it can't be implemented at this time. If it were clear this was being added in CoreFX I would reopen this issue. @alx9r let's watch those CoreFX issues and if they reach a point where it will be implemented we can either open a new issue or re-open this one.

Per dotnet/corefx#21577:

We have just merged support for changing cipher suites in SslStream: dotnet/corefx#24588 - currently Linux with OpenSsl 1.1.1 is or OSX is required.

@iSazonov Can you reopen this issue? My OP is still on-point AFAICT, and corefx now seems to have the support to make this possible.

[iSazonov]

We can continue after moving to .Net Core 3.0.

[markekraus]

Looks like it still needs to be surfaced in HttpClient/HttpClientHandler. Also, I'm not a fan of implementing this if it's not supported on all platforms and it is currently not supported on windows in SslStream. Might be something that could be managed as an experimental feature once available in HttpClient.