2

(If you're wondering why I'm trying to enable cipher suites that are deprecated, the short answer is that it's for the few people who really can't use anything newer because they're stuck on Windows Server 2003, neither we nor them can do anything about it and we don't want the service we supply them with to stop working if we can help it.)

I have used IIS Crypto to enable a number of protocols, ciphers, hashes, key exchanges and cipher suites (here is a full listing) that should encompass what's necessary for our product to connect to this server over TLS 1.0 considering Schannel's capabilities in Windows Server 2003. (The server has been rebooted since the changes were applied in IIS Crypto.)

However, the server drops the connection and documents it with the following two event log entries, posted by Schannel in the System event log:

"An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed." - event ID 36874

followed by

"A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205." - event ID 36888

Using Wireshark on the client, I can see that it is trying to negotiate the following cipher suites:

            Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
            Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
            Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
            Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)

of which these:

TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA

are included in what I enabled with IIS Crypto. Yet still the server doesn't want to touch these cipher suites and allow a connection to be made. It just drops the connection instead, as evidenced by this attempt to connect using OpenSSL.

Why is IIS or Schannel not allowing the use of these cipher suites when, as far as I can tell, I have configured them both to use them regardless of the defaults?

Jesper
  • 115

3 Answers3

2

I know this is old, but in case someone wants to know more, there are also locations within the registry for this. My thought is that perhaps TLS 1.0 is Enabled=0 or DisabledByDefault=1?

SSL / TSL:

Registry location: \HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

If there are keys in the Protocols registry folder with sub keys of Client and Server, and DWORDS within them of DisabledByDefault and Enabled, then that is what is configuring it. The default state for Win 2012 (r1) was TLS1 was allowed and allowed by default. (If not, you can add them in)

(Note that Server is for incoming connections, and client for outbound.)

References:

Ciphers:

Registry location: \HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

We used IIS Crypto too, after researching a lot, and finding that everyone just uses this program. (It freed us up from having a 1023 char limit on the Cipher Suite list in Group Policy Editor.)

(Aside: Win XP will loose all connectivity with HTTPS if 3DES (triple DES) gets culled)

References:

Mark
  • 147
1

TL;DR: Gave up and used Linux and Nginx.

I never found the answer to what was missing. Beyond the Windows Server 2012 R2 server mentioned, I set up a Windows Server 2008 R2 server and fully updated that and used IIS Crypto in the same way, and it seems to me like there's been some sort of RC4 kill switch deployed in some update along the line that is unable to be deactivated in the documented way, especially because another Windows Server 2012 R2 server that has not been down for patching does not do the same thing.

Since I can't live in fear of running Windows Update, I had to resort to setting up an Ubuntu server running Nginx, handling TLS termination and reverse proxying to the server on plain HTTP on the server that now I didn't have to expose publicly. Microsoft's lack of exhaustive and accurate documentation and desire to dramatically change behavior in minor updates shows contempt for their customers and their businesses, and they would do well to look to their competitors for lessons on how to care about their customers' security while still trusting them with their own judgement.

Jesper
  • 115
0

Most organisation will follow the IIS 8 hardening guidelines here: https://benchmarks.cisecurity.org/tools2/iis/CIS_Microsoft_IIS_8_Benchmark_v1.0.0.pdf

What I'd suggest you to check are the values defined here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 SchUseStrongCrypto

Turning on Strong Crypto automatically disables RC4 support, and it's not something which the IIS Crypto tool touches.

louis xie
  • 125