Can we add TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 on windows server 2012 using gpedit although not supported by windows OS by default?

Question

We are using IIS on Windows 2012-R2 server to host dotnet apps. From the app, when we try connecting to an external 3rd party api we see TLS handshake failure. On running ssllabs test on that api, I see that they support only below suites. .

On microsoft site I can see that our windows os version only supports some cipher suites, not exactly the one's we need to connect to the api. Here is the link : https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8 . The 2 GCM suites from above screenshots were added in 2016 version as per this article https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server .

On interception of outgoing traffic from our server using wireshark, I see below 22 suites were sent during clienthello. .

On some research I found that dotnet apps always use suites from OS, unless we write our own httpclient which I believe is not the right thing to do. Somehow I believe Postman and browsers have their own clients, so I'm able to reach the api using those apps running on our same server.

So we tried adding TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 by using gpedit.msc and restarted. Now I see on IISCrypto that these suites are enabled. But we still see same handshake error and I can see on wireshark, same 22 suites are sent across.

So my questions are,

1. Can we not enable suites like this and in our servers? (Other than by updating server to 2016), If not why does IIScrypto show that its enabled. Is it ignored by our apps even if we forcefully apply because of some reason or am I missing any step?

2. How only 22 suites were chosen for TLS handshake by server though there were 38 suites enabled before we updated them using gpedit. Are they all not for https?

Here is the screenshot :

Answer 1

1. If the version of SChannel (the code Microsoft wrote that implements TLS in Windows) doesn't support a cipher suite, then enabling it in the registry will not affect anything. The registry stores a list of values, and the code uses that list to enable and disable features the code supports. If the code doesn't support the feature, it ignores the value in the list in the registry.

2. The _P256, _P384 (and _P521) variants affect a TLS extension that lists supported curves, it doesn't affect the list of supported cipher suites. SSL_CK_ are not supported (they are for SSLv2). That I think explains the discrepancy you see.