问题
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?
回答1:
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.
回答2:
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).
来源：https://stackoverflow.com/questions/35513969/schannel-issue-with-windows-10