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

我们目前在基于web的应用程序中遇到问题。它在任何操作系统win2k12 R2和更高版本的IIS上运行良好。该应用程序是针对.net Framework 4.5.1编译的。虽然我们知道较新的.NET Framework版本，但由于一些不方便的第三方依赖关系，我们仍在努力进行更新

最近，微软发布了KBs，其中隐式安装了.NETFramework 4.7.2。安装了这些更新的客户现在面临一个重大问题

下面的代码虽然过于简化，但包含了所有必要的信息

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;
            }
        }

在安装了.NET Framework 4.7.2的系统上执行此操作时，在

GetResponse（）

调用中会出现以下错误：

“基础连接已关闭：发送时发生意外错误。”

内部的例外是：

“身份验证失败，因为远程方已关闭传输流。”

位于System.Net.Security.SslState.StartReadFrame（字节[]缓冲区，Int32 readBytes，AsyncProtocolRequest asyncRequest）
位于System.Net.Security.SslState.StartReceiveBlob（字节[]缓冲区，AsyncProtocolRequest asyncRequest）
在System.Net.Security.SslState.CheckCompletionBeforeNextReceive（ProtocolToken消息，AsyncProtocolRequest asyncRequest）
位于System.Net.Security.SslState.ForceAuthentication（布尔值receiveFirst，字节[]缓冲区，AsyncProtocolRequest asyncRequest）
在System.Net.Security.SslState.ProcessAuthentication（LazyAsyncResult-lazyResult）上
位于System.Threading.ExecutionContext.RunInternal（ExecutionContext ExecutionContext、ContextCallback回调、对象状态、布尔值preserveSyncCtx）
在System.Threading.ExecutionContext.Run（ExecutionContext ExecutionContext，ContextCallback回调，对象状态，布尔保存SyncCTX）
在System.Threading.ExecutionContext.Run（ExecutionContext ExecutionContext，ContextCallback回调，对象状态）
在System.Net.TlsStream.ProcessAuthentication（LazyAsyncResult）上
在System.Net.TlsStream.Write（字节[]缓冲区，Int32偏移量，Int32大小）
在System.Net.ConnectStream.WriteHeaders（布尔异步）

卸载前面提到的KBs和.NET Framework 4.7.2确实有帮助，但对于我们的客户群来说不是一个选项

到目前为止，我们尝试的其他选择是：

按如下方式设置注册表项：

[HKEY\U LOCAL\U MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions”=dword:0000000 1
“SchUseStrongCrypto”=dword:00000001

同时注释ServicePointManager.SecurityProtocol属性中tls 1.2的显式设置 （来源：）

设置AppContextSwitchs：

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

（来源：）

到目前为止，我们无法对抛出的异常进行任何更改。 有人能给我们指出正确的方向吗

提前非常感谢

更新：

根据评论中的建议，我们进行了几次wireshark跟踪

在未安装Framework 4.7.2的情况下，我们的应用程序与服务器应用程序成功协商（正如我们的代码示例所示）：

之后，我们将代码更改为专门设置tls 1.1，只是为了确认设置ServicePointManager.SecurityProtocol会产生影响，我们发现，毫无疑问，应用程序无法协商tls 1.1：

有趣的是，我们再次安装了.NETFramework4.7.2，重新设置了代码，特别是

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

并再次追踪电话。现在，让我们惊讶的是，该应用程序试图协商tls 1.0，但这当然失败了：

之后，我们通过以下方式专门禁用了操作系统上的tls 1.0：

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

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

---

再次查看Wireshark，应用程序尝试协商ssl3.0。回到注册表，并特别禁用该注册表，Wireshark中不再显示ClientHello，例外情况是，找不到连接到服务器的共同算法。

尝试设置这些注册表设置：

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

之后，在发出HTTPWebRequest之前，请包括ServicePointManager更改：

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

---

这将迫使您的应用程序使用TLS1.2。我没有看到任何迹象表明你一次尝试了以上所有方法，而这样做对我们来说是有效的

这听起来可能是个奇怪的问题，但你试过哪些客户？我唯一的想法是，更新可能引入了一个新的TLS密码套件，该套件可能无法与浏览器/客户端PC协同工作。例如，Chrome使用自己的TLS逻辑，而IE和.NET代码与Windows的设置相匹配。我很想知道他们是否会对你的错误产生不同的结果。进行网络捕获/wireshark还可以了解正在协商哪些协议。比较好的协商和坏的协商可能表明握手的哪一部分导致协商失败。服务器是否可能不支持TLS1.2？这可以解释这个错误。另一个选择是查看Wireshark跟踪，查看故障的详细信息……谢谢，伙计们！我已经用wireshark跟踪更新了这个问题。在服务器上安装IIsCrypto以检查服务器上启用了哪些TLS版本，应用程序正在从哪个服务器运行，确保远程方（webservice或DB server）也实现了TLS 1。2@ABDmaverick谢谢你的提示；IISCrypto告诉我运行应用程序的计算机的出厂默认值（Win 10）。我做了一些调整，设置了“最佳实践”选项，只启用了TLS 1.0-1.2，仍然尝试协商TLS 1.0，我将协议限制为仅TLS 1.2，除了计算机上几乎所有的应用程序崩溃之外，我的应用程序没有协商任何内容，抛出的异常表示没有可以使用的相互算法。。。来自不同的计算机

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;