安装.net Framework 4.7.2时，TLS1.2协商在4.5.1应用程序中失败

Question

we are currently experiencing an issue with our web based application. It runs well under any OS win2k12 R2 and higher on an IIS. The application is compiled targeting .net Framework 4.5.1. Whilst we are aware of newer .NET Framework versions, we struggle with the update due to several inconvenient 3rd party dependencies.

Recently, Microsoft released KBs which implicitly installed .NET Framework 4.7.2. It is customers with these updates installed, that face a major issue right now.

The following code, while oversimplified, contains all necessary information.

private HttpWebResponse GetResponse(HttpWebRequest httpWebRequest)
{
            lock (Statics._lockObject)
            {

                HttpWebResponse httpResponse = null;
                SecurityProtocolType tempProtocol = ServicePointManager.SecurityProtocol;

                //ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

                ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;   // Magic Number equals SecurityProtocolType.Tls1.2 
                ServicePointManager.ServerCertificateValidationCallback = CheckSSL;
                try
                {
                    httpResponse = (HttpWebResponse)httpWebRequest.GetResponse();
                }
                catch (Exception ex) 
                {
                    System.Diagnostics.Debug.WriteLine(ex.Message + Environment.NewLine + ex.StackTrace);
                }
                finally
                {
                    ServicePointManager.SecurityProtocol = tempProtocol;
                    ServicePointManager.ServerCertificateValidationCallback = null;
                }
                return httpResponse;
            }
        }

When executing this on a system that has .NET Framework 4.7.2 installed, we get the following error within the GetResponse() call:

"The underlying connection was closed: An unexpected error occurred on a send."

 at System.Net.HttpWebRequest.GetResponse()

and the inner exception:

"Authentication failed because the remote party has closed the transport stream."

at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async)

Uninstalling the aforementioned KBs and thus, .NET Framework 4.7.2, does help, but is no option for our customer base.

So far, the other options we tried are:

setting registry keys as followed: [HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\.NETFramework\\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001

whilst commenting out the explicit setting of tls 1.2 in the ServicePointManager.SecurityProtocol property (source: https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls#schusestrongcrypto )

setting appcontextswitches:

Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols

(source: https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element )

So far, we are unable to get any change in regard to the exception thrown. Can anyone point us in the right direction?

Thank you very much in advance!

Update:

Due to recommendation in the comments, we made a couple of wireshark traces.

Without Framework 4.7.2 installed, our application negotiates - just as our code sample suggests - tls 1.2 successfully with the server application:

Afterwards, we changed the code to specifically set tls 1.1 only to confirm that setting ServicePointManager.SecurityProtocol makes an impact an we see, to no surprise, the application fails to negotiate tls 1.1:

Now for the fun part, we installed .NET Framework 4.7.2 again, resetted the code to specifically say

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

and traced the call again. Now, to our surprise, the app tries to negotiate tls 1.0, which of course fails:

Afterwards, we specifically disabled tls 1.0 on the OS via:

`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client

"Enabled"=dword:0000000
"DisabledByDefault"=dword:00000001 `

Looking at Wireshark again, the application tried to negotiate ssl3.0. Back to the registry and specifically disabling that one as well, there was no more ClientHello shown in Wireshark and the exception said, that no mutual algorithm could be found to connect to the server.

Answer 1

Try setting these registry settings:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 
   Value: SchUseStrongCrypto 
     Data: 1

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server    
   Value: Enabled
     Data: 0
   Value: DisabledByDefault
     Data: 1

After that, before making your HTTPWebRequest include the ServicePointManager change:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

That should force your application to TLS 1.2. I didn't see anything saying you'd tried all the above at once, and doing this worked for us.