Lantrix Pro请求的更新

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

从我们为测试目的创建的.net客户端连接到严格的TLS 1.2没有任何问题

使用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握手有效。

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

Lantrix Pro请求的更新

1 个答案: