clienthello 后 SSL 握手失败答案

【问题标题】：SSL Handshake fails after clienthelloclienthello 后 SSL 握手失败
【发布时间】：2014-02-13 22:33:35
【问题描述】：

编辑：我将把它作为调试 SSL 的一个很好的例子。

最终分析：我们遇到了一个网络问题，其中我们的一个路由器被错误地配置为一个完全不同的应用程序，导致该路由器运行在 CPU 使用率的边缘。最初的几次握手并没有固定它……随后的一次握手没有固定它，并且由于路由器过载，连接被断开了。当它真的完全是另外一回事时，这表现为一个 SSL 问题。

要点：当 SSL 在中间连接中完全断开时，请务必检查您所控制的路由器的负载水平。

我已经有一段时间了，所以希望我能提供准确的图片。

我们在第三方提供商处拥有 SVN 和 Git 存储库。我们注意到每个都会间歇性地挂起，而屏幕上没有错误。在 SVN 的情况下，该进程必须在 Git 中被 kill -9ed 一个 ctrl-C 就足够了。

我发现 SSL 握手协商失败了。在 SVN 中，我们会到达握手部分，然后……什么都没有。

现在，我知道我们在没有已知问题的情况下在其他地方使用这些存储库，所以这是我遇到的第一个兔子洞。

这只发生在一个数据中心。不在我们的整个网络中。这些存储库在任何地方都很好，但是在这个数据中心，大约三分之一的请求挂在 SSL 握手上。
这些相同的机器可以访问 SSL 握手而在其他任何地方都没有问题，除了这个第三方提供商。

所以，我深入研究了 SSL 握手，最终登陆：

openssl s_client -msg -debug -state -connect DOMAIN.DOM:443 在这里停止：

CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x20b94e0 [0x20b9560] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 88 0a 00 73 97   ....8...4.....s.
0010 - 12 69 c9 00 65 29 10 f6-57 00 57 44 e8 0e 3f cf   .i..e)..W.WD..?.
0020 - af a0 f9 80 e2 20 98 f0-d2 79 8c 00 00 9e c0 30   ..... ...y.....0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3   .,.(.$.....".!..
0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32   ...k.j.9.8.....2
0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35   ...*.&.......=.5
0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d   ................
0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09   ...../.+.'.#....
0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32   .........g.@.3.2
0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25   .....E.D.1.-.).%
00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 c0 11   .......<./...A..
00b0 - c0 07 c0 0c c0 02 00 05-00 04 00 15 00 12 00 09   ................
00c0 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 6d   ...............m
00d0 - 00 0b 00 04 03 00 01 02-00 0a 00 34 00 32 00 0e   ...........4.2..
00e0 - 00 0d 00 19 00 0b 00 0c-00 18 00 09 00 0a 00 16   ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05   ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11   ................
0110 - 00 23 00 00 00 0d 00 20-00 1e 06 01 06 02 06 03   .#..... ........
0120 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02   ................
0130 - 03 03 02 01 02 02 02 03-00 0f 00 01 01            .............
>>> TLS 1.2 Handshake [length 0138], ClientHello
01 00 01 34 03 03 88 0a 00 73 97 12 69 c9 00 65
29 10 f6 57 00 57 44 e8 0e 3f cf af a0 f9 80 e2
20 98 f0 d2 79 8c 00 00 9e c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a c0 22 c0 21 00 a3 00 9f 00 6b 00
6a 00 39 00 38 00 88 00 87 c0 32 c0 2e c0 2a c0
26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 12 c0
08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0
2f c0 2b c0 27 c0 23 c0 13 c0 09 c0 1f c0 1e 00
a2 00 9e 00 67 00 40 00 33 00 32 00 9a 00 99 00
45 00 44 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00
9c 00 3c 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0
02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00
08 00 06 00 03 00 ff 01 00 00 6d 00 0b 00 04 03
00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00
0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00
06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00
01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00
0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
02 02 03 00 0f 00 01 01
SSL_connect:unknown state

它挂在那里。成功连接后，该调试输出的下一行应该是

read from 0x1735590 [0x173ab70] (7 bytes => 7 (0x7))
0000 - 16 03 03 00 42 02                                 ....B.
0007 - <SPACES/NULS>
read from 0x1735590 [0x173ab7a] (64 bytes => 64 (0x40))
0000 - 00 3e 03 03 52 fd 41 af-09 0b 96 d6 c4 01 c2 1b   .>..R.A.........
0010 - eb e9 23 71 93 a6 1b 78-df 67 17 fe 86 c4 f9 82   ..#q...x.g......
0020 - 53 4f 36 09 00 c0 30 00-00 16 ff 01 00 01 00 00   SO6...0.........
0030 - 0b 00 04 03 00 01 02 00-23 00 00 00 0f 00 01 01   ........#.......
<<< TLS 1.2 Handshake [length 0042], ServerHello

02 00 00 3e 03 03 52 fd 41 af 09 0b 96 d6 c4 01
c2 1b eb e9 23 71 93 a6 1b 78 df 67 17 fe 86 c4
f9 82 53 4f 36 09 00 c0 30 00 00 16 ff 01 00 01
00 00 0b 00 04 03 00 01 02 00 23 00 00 00 0f 00
01 01
SSL_connect:SSLv3 read server hello A

所以，正如您所见，这是握手接近完成之前的方式。

据我所知，我们的客户发起了握手 (cleinthello)，有时会在网络上保持沉默。

我已经尝试升级 openssl，没有任何变化。同样，这只是从这个数据中心连接到这个提供商。

我遇到了某种网络问题，以某种方式过滤了传出的 SSL 流量，但我不知道为什么会发生这种情况。

如果您有任何关于故障排除过程中下一步该去哪里的想法，我们将不胜感激。谢谢。

编辑：尝试了多种密码并且可以全部复制，再次导致我可能出现网络问题。

编辑：与 gnutls 类似的结果：

ifx14:/home/cadre/stresler# gnutls-cli -d 9 DOMAIN.DOM
Resolving 'DOMAIN.DOM'...
Connecting to 'X.X.X.X:443'...
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a11a60]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a11a60]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x1a11a60]: Sending extension CERT_TYPE
|<2>| EXT[0x1a11a60]: Sending extension SERVER_NAME
|<3>| HSK[0x1a11a60]: CLIENT HELLO was send [131 bytes]
|<4>| REC[0x1a11a60]: Sending Packet[0] Handshake(22) with length: 131
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a11a60]: Sent Packet[1] Handshake(22) with length: 136

【问题讨论】：

不幸的是，下一步是在第三方提供商处获得相同的交换视图。这将允许您将问题隔离到服务器或网络。
这里有代理或负载均衡器吗？我知道 F5 有一个大的ClientHello 的问题。 ClientHello 太大了，因为初始数据包中塞满了大约 80 个密码套件，而 F5 仅为初始数据包提供了一个固定大小的小型缓冲区。解决方法是 (1) 修补负载平衡器，或 (2) 减少密码套件。有关该问题的简要讨论，请参阅 OpenSSL 1.0.1e CipherSuites and TLS1.2 more mixed signals than my xgf。
openssl s_client -msg -debug -state -connect DOMAIN.DOM:443 - 您可以尝试添加 -tls1 选项。由于客户端和服务器损坏，TLSv1.2（和 TLSv1.1）几年前遇到了麻烦。 Ubuntu 仍然禁用 OpenSSL 的协议（参见 Ubuntu 12.04 LTS: OpenSSL downlevel version, and does not support TLS 1.2）。如果-tls1 解决了问题，那么您可能正在处理其中一台损坏的服务器（更重要的是，未打补丁的服务器）。
原来是我们的IP空间。我们在 198.16.*.*。我相信他们和我们之间的某些防火墙阻止的太广泛了，这意味着阻止 198.18.0.0/15 和 198.51.100.0/24 保留的 IP 空间。

标签： networking openssl

【解决方案1】：

这是旧的并且已经回答了，但是我们遇到了同样的问题并且原因不同。

关键是在我们的边缘路由器上嗅探流量，在那里我们看到了发往服务器 (GitHub.com) 的 ICMP 消息，要求分段。这使连接变得混乱，重传、重复的 ACK 等等。

ICMP 数据包有一个字段，MTU of next hop，其值为 1450。通常的值为 1500。

我们检查了我们的路由器，其中一个接口（以太网隧道）将此值作为 MTU，因此路由器将所有接口的最小 MTU 作为下一跳。一旦我们删除了这个接口（它未被使用），SSL 握手又开始工作了。

【讨论】：

我们在防火墙（用于 IPSec VPN）上将 MTU 设置为 1496 时遇到了类似的问题，在节点上将 MTU 设置为 1500。有趣的部分是我们在 SSL 握手时遇到了问题，仅对某些 HTTPS服务器（实际上是一个）。无论如何，在节点上将 MTU 设置为 1496 会有所帮助。非常感谢@charli 的回答！

【解决方案2】：

对于遇到此问题的人，我创建了一个清单：

确保在 Internet Explorer 中启用了所有 TLS 版本（这是为了测试。您可以稍后在找出根本原因后禁用不安全的版本）
检查下面的注册表项，确保您在 Internet Explorer 中设置的内容适用于注册表级别。如果有工作服务器和非工作服务器，镜像工作服务器的设置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
从客户端收集网络跟踪。检查客户端和服务器是否就密码套件达成一致。如果不是，请确保客户端使用服务器尝试使用的密码套件。组策略设置低于Computer Configuration > Administrative Templates > Network > SSL> Configuration Settings > SSL Cipher Suite Order
如果问题仍然存在，请查找可能会阻止 TLS 流量的任何网络设备（代理、防火墙、负载平衡器等）
检查 IIS 中的网站绑定。确保证书有效且端口设置为 443
确保在服务器中侦听端口 443 (netstat -an -p TCP | find /I "listening")。更多详细信息：IIS 服务器中未侦听端口 80 和 443 将端口号更改为 444 并测试网站。如果可以访问，则说明有软件阻塞或覆盖了 443 端口。 More details
禁用 Windows 防火墙（如果有效，您可以重新启用它并相应地设置规则）
在服务器中查找任何第三方应用程序，例如防病毒或端点保护软件，例如 Symantec Endpoint Security 和 Symantec Data Center Security Server Agent（基于this document，Security Server Agent 使用端口 443）。卸载它们（不要只是禁用。完全卸载。如果可行，您可以重新安装它们并进行相应的配置）
检查是否有任何 Microsoft 软件使用端口 443。SQL Server Reporting Services (SSRS) 和 Windows Admin Center 等应用程序可能会干扰端口 443。An example

来源：The missing Server Hello in TLS handshake (ERR_SSL_PROTOCOL_ERROR

【讨论】：

【解决方案3】：

正如我所见，客户端 hello 在位置 00cb 上多了一个字节：0xFF 不应该在那里。所以无法正确读取以下字节数据...

00c0 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 6d ....m

不确定，但它似乎是 openssl 中的一个错误，因此防火墙或 Web 代理会忽略该请求。

【讨论】：

【解决方案4】：

好吧，我遇到了类似的问题。 SSL 握手在 ClientHello 之后立即终止并出现错误。结果证明服务器需要比我安装的更强大的密码，所以我必须安装 Java Cryptography Extension (JCE) (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html)。

更有趣的是，我们在服务器上遇到了同样的问题，我们在那里有 JCE 的 jar，但有些旧版本，所以它遇到了同样的问题。用最新版本替换它们解决了这个问题。

顺便说一句，你知道如何获得所需的服务器密码吗？或者更好地比较客户端和服务器密码？所以人们会立即看到不匹配。

【讨论】：