Support changing cipher suites offered by Invoke-WebRequest and Invoke-RestMethod
See original GitHub issueInvoke-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
.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:8 (3 by maintainers)
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.
We can continue after moving to .Net Core 3.0.