1

I have an application that uses the System.Net.Security.SslStream class to make a secure connection to a server. On Windows 7 and Windows 8/8.1, this works fine. On Windows 10, the call to SslStream.AuthenticateAsClient throws an exception - "AuthenticationException: A call to SSPI failed, see inner exception". The inner exception is "Win32Exception: The Local Security Authority cannot be contacted". This is not specific to one Windows 10 machine.

I thought that it might have something to do with the length of the public key for the server certificate being 512 bits, so I created my own self-signed certificate with a 512 bit public key and tested SslStream.AuthenticateAsClient with it on the Windows 10 machine. This worked fine.

I am trying to figure out what changed in Windows 10 that is causing this to no longer work. Looking at the log generated by System.Net and a capture from Wireshark, I see that the client receives the SERVER HELLO, CERTIFICATE, and SERVER DONE messages, and then the client closes the connection. In the System event log, there is an error logged by SChannel - "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 813." Apparently TLS error code 40 is a handshake failure, but I have not been able to find anything about SChannel error state 813.

By looking at the SSL handshake in Wireshark, I have found that the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite is being used. When I connected to the test server that I created (which works with a 512 bit public key certificate), the TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA cipher suite is used. Is there an issue with using TLS_RSA_WITH_3DES_EDE_CBC_SHA on Windows 10?

Jeff
  • 41
  • 1
  • 4
  • To clarify, when you say "used", I presume you mean you saw it in the ServerHello. If you saw that in the ServerHello, then the server is agreeing to use that cipher suite since it was offered in the ClientHello, so it isn't a cipher suite issue. – vcsjones Feb 25 '16 at 19:01
  • Where exactly in the handshake is it failing? – vcsjones Feb 25 '16 at 19:16
  • Correct, that is the cipher suite that I see in the ServerHello. The handshake appears to complete successfully, but after receiving the ServerDone, the client immediately closes the connection. The InitializeSecurityContext function is returning error code 0x80090304. – Jeff Feb 25 '16 at 19:27
  • OK, so the way handshake works, the client sends a list of ciphers it supports, and the server picks one and responds in the ServerHello. So, we can see here that it isn't specifically the cipher suite since both client and server agreed on TLS_RSA_WITH_3DES_EDE_CBC_SHA. I *think* I know what is going on. I'll write an answer. – vcsjones Feb 25 '16 at 19:33

2 Answers2

2

We had similar issues with our .Net SSL client application which is connected to multiple servers using TLS1.0 and TLS1.2.

The problem is that TLS1.2 in Windows SChannel doesn't support some weak Cipher Suites, however for connections using TLS1.0 these Cipher Suites are allowed.

The behaviour of Windows system changed with .Net 4.6.1; before this version preferred protocol was TLS1.0, after update to version >=4.6.1 all .Net clients are automatically set to TLS 1.2. Also some KB security updates may affect the behaviour.

The first way is to modify the application to use strictly TLS1.0 (which is not correct from security view):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls

Second way is to use free tool IISCrypto which can help you to disable/enable your protocols and cipher suites: https://www.nartac.com/Products/IISCrypto IISCrypto-Ciphers-Selection

Note, the settings is stored in Windows Registry and is common for all protocols, you may need to "play" with configurations to find the one which fits best for all connections you're using.

Miroslav Jaroš
  • 21
  • 4
0

OK, so since you are seeing the cipher suite in the ServerHello, we can conclude that the cipher suite is supported by both the client and the server, so it isn't specifically the cipher suite that is the issue.

I suspect the problem is your 512-bit certificate when you are not using ECDHE or DHE in the cipher suite. If I recall correctly, Windows 10 requires 1024-bit (effective) or more for the key exchange. Since you are not using ECDHE or DHE for the key exchange, it is using RSA, and your certificate is 512-bits, so it tries to use 512-bit RSA for the key exchange portion. Your new server is not failing with a 512-bit certificate because it is using EC Diffie-Hellman.

You can test this by doing one of the following

  • Disabling all cipher suites on your new test server that use DHE or ECDHE.
  • Enabling DHE / ECDHE cipher suites on the "old" server.
  • Using a 1024-bit certificate on the "old" server (which I would recommend anyway since 512-bit is extremely weak).
vcsjones
  • 138,677
  • 31
  • 291
  • 286
  • I don't have access to the "old" server. I just created a simple TCP client application and TCP server application that use SSL to try to replicate the problem. If I disable all of the cipher suites on this test system that use DHE or ECDHE, the server application throws an exception after receiving the ClientHello - "The client and server cannot communicate, because they do not possess a common algorithm". This seems strange because the client and server are on the same machine. – Jeff Feb 25 '16 at 21:22
  • Also, your explanation regarding my test client/server working because ECDHE is being used for the key exchange makes sense. Is my understanding correct that when Diffie-Hellman is used for the key exchange, the certificate public key is not used at all? – Jeff Feb 25 '16 at 21:26