客户端和服务器无法通信，因为它们没有共同的算法 - SSLStream

Question

已经回答了很多类似的问题，但没有一个答案对我目前的情况有所帮助。

在 windows 服务中，我们有 TCPL SSL 流和连接到该流的客户端。

我已经创建了一个 .NET 客户端，并且能够使用 IIS Crypto 使用 Strict TLS 1.2 成功访问服务器。

我们正在尝试使用 Lantronix xport Pro 访问服务器，以下行抛出异常

stream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Ssl3| SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, True);

仅当启用严格的 TLS 1.2 时才会发生异常。如果我们启用了 SSL3 协议，一切正常，没有任何问题。

使用 WireShark 我可以看到客户端使用以下密码发送 TLS 1.2 请求

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

根据上面的 MSDN，密码支持 TLS 1.2

从我们使用严格的 TLS 1.2 进行测试而创建的 .net 客户端连接没有任何问题

使用 open ssl 创建自签名证书。服务器正在运行 windows server 2012 R2。

我不确定我应该为特定于 TLS 1.2 的 SSLstream 尝试哪些选项？

除了 .net 客户端进行通信之外，我还需要什么特定的东西吗？

任何有关跟踪此问题的建议都会很棒

关于 Lantrix Pro 请求的更新

Frame 33845: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0
Ethernet II, Src: Pronet_c7:bb:29 (00:20:4a:c7:bb:29), Dst: Vmware_99:95:c7 (00:50:56:99:95:c7)
Internet Protocol Version 4, Src: 10.10.110.71, Dst: 10.10.110.10
Transmission Control Protocol, Src Port: 38182, Dst Port: 28000, Seq: 1, Ack: 1, Len: 58
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 53
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 49
            Version: TLS 1.2 (0x0303)
            Random: 8a f5 6f 9e 92 65 43 c7 45 9b 57 ff dd a4 22 45 ...
                GMT Unix Time: Nov 16, 2043 20:38:22.000000000 Central Standard Time
                Random Bytes: 92 65 43 c7 45 9b 57 ff dd a4 22 45 12 16 cb 41 ...
            Session ID Length: 0
            Cipher Suites Length: 10
            Cipher Suites (5 suites)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)

Answer 1

TL;DR：客户端坏了。看起来供应商几乎没有为旧产品添加最少的 TLS 1.2 支持，同时保留了不安全的密码并且未能添加对当前使用的 SHA-256 签名证书的支持。

---

客户端只发送一个非常小的 TLS 1.2 握手。它仅包含 5 个密码（其中 3 个 EXPORT 密码严重不安全，3DES 密码稍微不安全，但 AES128-SHA 是可以接受的）。而且，与其他 TLS 成功的 1.2 握手相比，它不包含 signature_algorithm TLS 扩展。

此扩展是 TLS 1.2 的新增功能。它用于告诉服务器支持哪些签名算法。如果未提供扩展名，则默认为 SHA1 和 RSA 提供的密码。引用 RFC：

如果客户端不发送 signature_algorithms 扩展，则 服务器必须执行以下操作：

• 如果协商的密钥交换算法是（RSA、DHE_RSA、 DH_RSA、RSA_PSK、ECDH_RSA、ECDHE_RSA)，表现得好像客户端有 发送值 {sha1,rsa}。

但是，服务器提供了一个带有 RSA 密钥但使用 SHA-256 作为哈希的证书。因此，该证书将与接受的签名算法不匹配，并且握手失败。如果服务器改为允许 TLS 1.1 或更低版本，则握手将成功，因为这些较低协议版本会忽略 signature_algorithm 扩展，因此服务器可以发送它拥有的 SHA-256 签名证书。

从提供的 pcaps 中的 openssl s_client 捕获中可以看出，如果客户端提供 signature_algorithm 扩展并表示支持 RSA 和 SHA-256，则 TLS 1.2 握手有效。