Invoke-WebRequest HandshakeFailure with TLS_ECDHE_ECDSA_WITH_AES about powershell HOT 9 OPEN

The TLS settings on newer dotnet versions just fallback to the OS settings as this isn't controlled at all by dotnet or PowerShell at this layer. Using tls-web-server.py which allows you to create a standalone HTTP TLS service where you can restrict the TLS versions and ciphers as a test:

$ ./tls_web_server.py --tls-max-protocol TLSv1_2 --tls-ciphers ECDHE-ECDSA-AES256-GCM-SHA384
Listening on ('0.0.0.0', 39331)
192.168.56.15 - - [23/Feb/2024 06:12:42] "GET /get HTTP/1.1" 200 -
TLS Client {'protocol': 'TLSv1.2', 'cipher': 'ECDHE-ECDSA-AES256-GCM-SHA384', 'client_cert': None}

Then in PowerShell I did a GET request to that endpoint

PS > invoke-webrequest -uri https://192.168.56.1:39331/get -SkipCertificateCheck

StatusCode        : 200
StatusDescription : OK
Content           : {"tls": {"protocol": "TLSv1.2", "cipher": "ECDHE-ECDSA-AES256-GCM-SHA384", "client_cert": null}, "request_headers": {"Host": "192.168.56.1:39331",
                    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Microsof…
RawContent        : HTTP/1.0 200 OK
                    Server: BaseHTTP/0.6
                    Server: Python/3.11.5
                    Date: Thu, 22 Feb 2024 20:12:42 GMT
                    Content-Type: application/json; charset=utf-8

                    {"tls": {"protocol": "TLSv1.2", "cipher": "ECDHE-ECD…
Headers           : {[Server, System.String[]], [Date, System.String[]], [Content-Type, System.String[]]}
Images            : {}
InputFields       : {}
Links             : {}
RawContentLength  : 288
RelationLink      : {}

You can see there is no fundamental reason why it wouldn't work in PowerShell with Invoke-WebRequest. One thing you do need to make sure on is that the certificate you used on the web service end is configured with an ECDSA based key. If it's using an RSA key then the TLS handshake will fail with the error message you supplied.

from powershell.

My goal is to check a bunch of URLs

Depending on what information you want to recover, these are two cross platform tools;

$ openssl s_client -showcerts -connect www.github.com:443 </dev/null

This can be used to get the SSL certificate of a server without validating it.

Alternatively you can use Java's keytool

$ keytool -printcert -sslserver www.github.com:443

from powershell.

As per the request in #5159, this isn't really possible to do cross platform. While you can configure what TLS protocols are used through the CipherSuitesPolicy, the underlying .NET library does not offer a cross platform way to restrict the cipher suites that are offered by the client. It's currently restricted to Linux/macOS because the underlying TLS library on Windows does not expose the ability to do so from a client connection, just system wide.

from powershell.

Thank you @jborean93,

your tls-web-server.py works like a charm and invoke-webrequest is working as I expect.

But unfortunatly the "blackbox" Java-Based Werdserver I need to monitor, still says 'HandshakeFailure' if I try to connect.
With linux based "testssl" It could connect with the mentioned "#Cipher Suites Supported by the requested System: "

As I could not change much on the Server and the "Cipher Suites" should work with Powershell, as I tested by myself, is there some other option to check the TLS-Endpoint?

Maybe invoke-webrequest is not the best way to check the service, since it is in fact an AS4 Service (https://en.wikipedia.org/wiki/AS4), my goal is to check wether the Service is UP (some Status Code?) and maybe something like the "Common Name" (CN) and the "subjectAltName" (SAN) of the Certificate.

AS4 - Wikipedia

from powershell.

As I could not change much on the Server and the "Cipher Suites" should work with Powershell, as I tested by myself, is there some other option to check the TLS-Endpoint?

It is interesting because my Python web server didn't work with that particular cipher until I added the ECDSA certificate generation. It could be that your webserver is using a RSA based certificate and testssl is able to handle that while Schannel cannot. I don't think that's the issue but at this point you might need to look into the network captures in a tool like Wireshark to compare the exchange.

Maybe invoke-webrequest is not the best way to check the service, since it is in fact an AS4 Service (https://en.wikipedia.org/wiki/AS4), my goal is to check wether the Service is UP (some Status Code?) and maybe something like the "Common Name" (CN) and the "subjectAltName" (SAN) of the Certificate.

Invoke-WebRequest is certainly a few layers above testing just TLS. You could use something like Test-Tls to test just the TLS handshake but the error you shared initially means the handshake itself failed so this should most likely do the same.

AS4 - Wikipedia

from powershell.

The Java Keytool and Openssl worked, so do I need to use third party tools? I was hoping I could query these things with the native Powershell. thanks anyway

from powershell.

If openssl and keytool works then it sounds like your Java server is providing data in a format that is incompatible with Schannel when using that cipher suite. Schannel is what PowerShell and most other native TLS tools use on Windows.

from powershell.

Schannel is what PowerShell and most other native TLS tools use on Windows.

Might be worth trying the equivalent PowerShell on Linux, say in docker or WSL.

from powershell.

It will use OpenSSL as that is what dotnet links to on non-Windows.

from powershell.