asp.net - 为什么从 VBScript 调用 ASP.NET ASHX 处理程序有效，但在 .NET 中出现 "could not create SSL/TLS secure channel"错误？

Question

最近，我们的一个 ASP.NET ASHX 处理程序调用另一台服务器上的另一个 ASHX 处理程序开始失败，并出现以下错误:“未处理的异常:System.Net.WebException:请求被中止:无法创建SSL/TLS 安全通道。”为另一台服务器安装证书没有帮助(无论如何，另一台服务器是面向公众的并且具有由 CA 签名的证书)。

我写了一个小的 C# 程序来测试我是否可以从命令行连接到其他服务器:

using System.Net;

public class Test
{
    const string theUrl = "https://www.example.com/Handler.ashx?ID=123";
    public static void Main(string[] args)
    {
        var req = WebRequest.Create(theUrl);
        var resp = req.GetResponse();
    }
}

这也因 System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel 而失败。但是，如果我从 VBScript 文件调用处理程序:

Const theUrl = "https://www.example.com/Handler.ashx?ID=123"

Dim oXmlHttp

Set oXmlHttp = WScript.CreateObject("Microsoft.XMLHTTP")
With oXmlHttp
    .Open "GET", theUrl, False
    .Send

    WScript.Echo CStr(.Status)
End With

Set oXmlHttp = Nothing

它有效；脚本返回状态 200!

我检查了 .NET machine.config 文件，因为我在过去遇到过类似的问题，从非托管代码发送的请求有效，但从 .NET 发送的请求无效，因为代理设置不同，但这是这里不是这种情况。为什么来自 VBScript 的请求应该工作但来自 .NET 的请求失败？

编辑:启用跟踪会显示与 this question 中报告的错误类似的错误:

System.Net Information: 0 : [28468] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 1ad5f0:29f3620, targetName = www.example.com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)
System.Net Information: 0 : [28468] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=AlgorithmMismatch).
System.Net.Sockets Verbose: 0 : [28468] Socket#3741682::Dispose()
System.Net Error: 0 : [28468] Exception in the HttpWebRequest#2383799:: - The request was aborted: Could not create SSL/TLS secure channel.
System.Net Error: 0 : [28468] Exception in the HttpWebRequest#2383799::GetResponse - The request was aborted: Could not create SSL/TLS secure channel.

Answer 1

“算法不匹配”有点含糊，特别是因为 TLS 错误是 well defined .没关系。

运行 ssl-enum-ciphers (perl) 或 nmap's equivalent针对服务器查看它支持和喜欢的 SSL/TLS 版本和密码。紧要关头你可以试试 MS wfetch做类似的事情，但它的协议(protocol)和密码支持非常有限。您可以使用 openssl 作为服务器(需要 key +证书)为客户端做同样的事情:

openssl s_server -quiet -accept 4443 -key server.key -cert server.crt

可选地混合 -no_xxx 或 -xxx 其中 xxx 是 ssl2, ssl3 之一, tls1 的多样性。

(浏览器友好，但不太容易编码/自动化是 https://www.ssllabs.com/ssltest/viewMyClient.html 或查看 here 了解更多信息。)

协议(protocol)/密码协议(protocol)的工作方式是客户端发送 (ClientHello) SSL/TLS 版本、密码列表(和扩展)，然后服务器选择协议(protocol)版本和共同密码(相交集)并回复 (ServerHello)。选择的(粗略)方法是:

• 使用客户端支持的最高 SSL/TLS 版本，或者放弃(可能握手失败)
• 首选客户端列表中的第一个常用密码，即假设它是按偏好排序的
• -或者- 首选服务器列表中的第一个常用密码^[1]
• -或者- 放弃(没有通用密码)

^[1] this allows the operator to configure the server prefer ciphers based on other than "strength" (symmetric key-size), e.g. to force 128-bit RC4 over AES-256 while supporting both, as was the style a year or two back.

默认的密码顺序通常是按“强度”(对称密码 key 大小)降序排列。 SSL/TLS 协议(protocol)版本设置了一组预期的密码，但支持相同的密码(例如 AES-128)是不够的。

可能是客户端不使用 TLS，而服务器不使用 SSL，例如https://serverfault.com/questions/208542/what-might-cause-https-failure-when-not-specifying-ssl-protocol不过，这应该会导致协议(protocol)或握手错误。

由于通过 SecurityProtocolType.Ssl3(另一种情况 here)强制协议(protocol)，看起来客户端提出了一些服务器不喜欢的东西——如果你已经确认双方都支持 TLS那么它可能是 SNI 绊倒了你，然后回退到 SSL3 回避了这一点。

万一客户端默认为 SSlv2，服务器拒绝它是完全正确的；-)