SSL / TLS握手完成之前的连接重置 [英] Connection Reset Before SSL/TLS Handshake Completes

问题描述

我支持通过SSL / TLS回调WCF服务的桌面应用程序。  在我们安装桌面应用程序的10,000个左右客户端中，20个左右开始报告安装KB4014511后连接到WCF服务的问题。  报告的
错误是：

System.IO.IOException：无法将数据写入传输连接：远程强制关闭现有连接主办。 ---> System.Net.Sockets.SocketException：现有连接被远程主机强行关闭

在机器上运行Wireshark，我们看到在打开与服务器的TCP连接后，SSL / TLS握手永远不会启动，10秒后服务器重置连接：

[省略了屏幕截图，因为帐户没有已验证]

但是，在启动WCF调用后大约30秒抛出异常。   30秒后，服务器确实重置了连接，但奇怪的部分是为什么在
开始SSL / TLS握手之前有30秒的暂停？

使用API​​ Monitor，我们发现延迟的来源是对CryptFindOIDInfo的2次调用。  看起来这些调用是为了获得1.3.6.1.5.5.7.3.1（服务证书）和1.3.6.1.5.5.7.3.2（客户证书）的友好名称。
 这与KB4014511中描述的更改非常吻合。

现在，我们的10,000多个安装中只有20个左右受到此问题的影响。  受影响的已经成为具有域控制器的网络的一部分。   CryptFindOIDInfo的文档确实表示"  CryptFindOIDInfo   function
在活动目录中执行查找，以在以下条件下检索友好的OID名称..."。  再次检查Wireshark曲线我注意到以下  SMB_NETLOGON  在打开TCP连接和连接重置之间请求
：

[屏幕截图省略，因为帐户尚未经过验证]

因此，对于这台特定的机器，它无法通过域控制器进行身份验证。  我假设此身份验证
尝试是OID的AD查找的前身。  这些计算机上的网络配置似乎有问题，无法进行WCF调用。  尽管如此，此问题仅在
KB4014511安装在计算机上后才会出现。  我查看了补丁中更新的System.Net.Security.SecureChannel类的反编译代码，发现添加了2个新字段，m_ServerAuthOid和m_ClientAuthOid：

[屏幕截图已省略，因为帐户尚未经过验证]

这些字段初始化为类初始化的一部分，触发Oid查找。

这对我们的软件造成了很大的问题，因为曾经有效的代码，由于Windows补丁而不再有效，并且我没有找到解决办法来自客户机器的安全补丁。
 我不想从事卸载安全补丁的工作，那么我们可以使用其他任何解决方法吗？

解决方案

您好cinjguy，

对于SSL证书，是否指定了EKU？

根据此KB4014511，您的证书应具有EKU。

如果您暂时无法正确访问重新颁发的证书，则可以选择在所有计算机操作中选择加入或退出安全更改，以避免任何连接影响。

我建议你参考下面的链接获取更多信息。

#Windows 7 SP1的.NET Framework 4.6和4.6.1的安全性和质量汇总说明Windows Server 2008 R2 SP1和适用于Windows Server 2008 SP2的.NET Framework 4.6：2017年5月9日

https://support.microsoft.com/en-us / help / 4014511 /描述安全和质量汇总 - 网络框架-4

最诚挚的问候，

Edward

I support a Desktop Application that calls back to a WCF service over SSL/TLS.  Of the 10,000 or so clients we have with the Desktop app installed, 20 or so started reporting issues connecting to the WCF service after installing KB4014511.  The error being reported is:

System.IO.IOException: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

Running Wireshark on the machine, we see that after opening the TCP connection with the server, the SSL/TLS handshake never starts, and after 10 seconds the server resets the connection:

[Screenshot omitted because account has not been verified]

The exception however is thrown approximately 30 seconds after the WCF call is initiated.  After 30 seconds, it is true that the server did reset the connection, but the strange part is why is there a 30 second pause before beginning the SSL/TLS handshake?

Using API Monitor, we were able to find that the source of the delay is 2 calls to CryptFindOIDInfo.  It looks like these calls are being made to get the friendly name for 1.3.6.1.5.5.7.3.1 (Service Certificate) and 1.3.6.1.5.5.7.3.2 (Client Certificate).  This lines up pretty well with the change described in KB4014511.

Now only 20 or so of our 10,000+ installations are being impacted by this issue.  The ones that are impacted have been part of a network with a domain controller.  The docs for CryptFindOIDInfo do indicate that "The CryptFindOIDInfo function performs a lookup in the active directory to retrieve the friendly names of OIDs under the following conditions...".  Reviewing the Wireshark trace again I noticed the following SMB_NETLOGON requests between opening the TCP connection and the connection reset:

[Screenshot omitted because account has not been verified]

So for this particular machine, it is having trouble authenticating with the domain controller.  I am assuming this authentication attempt is a precursor to the AD lookup of the OID.  It would appear that there is something wrong with the network configuration on these machines that are have having trouble making WCF calls.  Nonetheless, this problem only appeared after KB4014511 was installed on the machines.  I reviewed the decompiled code for System.Net.Security.SecureChannel class that was updated in the patch, and found 2 new fields had been added, m_ServerAuthOid and m_ClientAuthOid:

[Screenshot omitted because account has not been verified]

These fields are initialized as part of the class initialization, which triggers the Oid lookups.

This creates a big problem for our software, in that code that once worked, no longer works because of a Windows patch, and there is no workaround that I can see short of removing the security patch from the clients' machines.  I do not want to be in the business of uninstalling security patches, so is there any other workaround that we could use?

解决方案

Hi cinjguy,

For certificate over SSL, is the EKU specified?

Per to this KB4014511, your certificate should have EKU.

If you temporarily can’t access correctly reissued certificates, you can choose to opt in or out of the security change across all computer operations to avoid any connectivity effects.

I would suggest you refer below link for more information.

# Description of the Security and Quality Rollup for the .NET Framework 4.6 and 4.6.1 for Windows 7 SP1 and Windows Server 2008 R2 SP1 and the .NET Framework 4.6 for Windows Server 2008 SP2: May 9, 2017

https://support.microsoft.com/en-us/help/4014511/description-of-the-security-and-quality-rollup-for-the-net-framework-4

Best Regards,

Edward

这篇关于SSL / TLS握手完成之前的连接重置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！