KB4344167安全更新破坏了TLS代码。

Question

希望有人能够帮助解决这个问题。最近，我们的机器更新了KB4344167，其中包括.NET 4.7.1的安全更新。不幸的是，这个更新破坏了我们的Webrequest代码。当我们运行下面的代码时，会出现以下错误：

请求被中止: 无法创建 SSL/TLS 安全信道。

// Create a request for the URL.        
WebRequest request = WebRequest.Create(url);
//specify to use TLS 1.2 as default connection
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
request.Timeout = int.Parse(configmanager.GetSetting("Webtimeout"));
// Set proxy
request.Proxy = WebRequest.DefaultWebProxy;
request.Proxy.Credentials = CredentialCache.DefaultCredentials;
// Define a cache policy for this request only. 
HttpRequestCachePolicy noCachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.NoCacheNoStore);
request.CachePolicy = noCachePolicy;
ServicePointManager.ServerCertificateValidationCallback = (s, cert, chain, ssl) => true;
// Get the response.
HttpWebResponse response = (HttpWebResponse)request.GetResponse();

当从计算机中卸载安全更新后，代码可以正常执行。我们在上面的代码中是否遗漏了什么？这是我能想到的唯一问题。

任何帮助都将不胜感激！

- DennisC

---

由于安全漏洞，TLS 1.1已被弃用，您尝试过从安全协议中移除该标志吗？ - Ron Beyer

参见 https://learn.microsoft.com/zh-cn/dotnet/framework/network-programming/tls - Heretic Monkey

据我所知，ServicePointManager.SecurityProtocol 在Create()调用期间被访问或复制。在此之后更改它应该没有明显的影响（无论在应用任何修复程序之前还是之后）。 - Damien_The_Unbeliever

Damien的评论很恰当：由于该行代码所在的位置，应用程序中只有第二个请求才能获取设置；在更改之前创建的Web请求将复制现有设置。这可能在实践中有所不同，具体取决于您的应用程序如何发出请求，但无论如何，这都不是您想要的。它可能不是此问题的原因，但仍然令人困惑。 - Jeroen Mostert

但是那行代码仍然允许TLS 1.1和TLS 1.0，就我所知，它并不起作用。从你在一些评论中说的话来看，我强烈怀疑你仍然实际上连接了较低的TLS级别，而更新现在正在阻止这种情况。也就是说，它从未按照你想象的那样工作。 - Damien_The_Unbeliever

Answer 1

@Damien_The_Unbeliever的答案是正确的。最终问题出在ServicePointManager和Webrequest.Create的顺序上。将这些行反转，即定义ServicePointManager在Webrequest.Create之前，就可以解决问题。当我们的服务器升级到TLS 1.2时，我仍然不知道为什么在Create之后添加ServicePointManager可以修复我们最初的问题，但现在我们不会再担心这个问题了。

- DennisC

Answer 2

我遇到了类似的问题。看起来微软在尝试仅启用TLS 1.2时可能破坏了某些东西。

到目前为止，我已经尝试将建议的配置添加到app.config中，并且它像魔法一样奏效。不再出现SSL / TLS错误。

<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false" /> </runtime>

注意：我们发现这是在有选择性地打补丁的服务器上发生的，即它们还没有安装微软的修复程序。我们的开发机器从未遇到过这个问题。

- Michael Silver