如何追踪“SSL 握手期间的连接超时”和“SSL 握手期间的连接关闭”错误答案

【问题标题】：How to track down "Connection timout during SSL handshake" and "Connection closed during ssl handshake" errors如何追踪“SSL 握手期间的连接超时”和“SSL 握手期间的连接关闭”错误
【发布时间】：2013-07-04 22:27:48
【问题描述】：

我最近从 AWS ELB 切换到 HAProxy。我正在负载均衡器 (HAProxy 1.5dev19) 处终止 SSL。

自从切换后，我在 HAProxy 日志中不断收到一些 SSL 连接错误（占请求总数的 5-10%）。重复出现三种类型的错误： SSL 握手期间连接关闭 SSL 握手期间超时 SSL 握手失败（这种情况很少发生）

我正在使用免费的 StartSSL 证书，所以我的第一个想法是某些主机在接受此证书时遇到问题，而我过去没有看到这些错误，因为 ELB 不提供日志记录。唯一的问题是一些主机最终确实有成功的连接。

我可以毫无错误地连接到服务器，所以我不确定如何在我的端复制这些错误。

【问题讨论】：

标签： ssl haproxy

【解决方案1】：

我也遇到过这种情况。以下首先出现SSL handshake failure，然后在关闭option dontlognull 后，我们还在haproxy 日志中得到Timeout during SSL handshake。

起初，我确保所有defaults 超时都是正确的。

timeout connect 30s
timeout client  30s
timeout server  60s

很遗憾，问题出在frontend 部分

timeout client 60 有一行，我只假设它的意思是 60ms 而不是 60s。

似乎某些客户端连接缓慢，并且在 SSL 握手期间被踢出。检查您的前端是否有客户端超时。

【讨论】：

谢谢，阿德南。这确实是问题所在，我在对蒂姆的回答的评论中记录了这一点。

【解决方案2】：

你的 haproxy ssl 前端是如何配置的？

例如，我使用以下方法来缓解 BEAST 攻击：绑定 X.X.X.X:443 ssl crt /etc/haproxy/ssl/XXXX.pem no-sslv3 密码 RC4-SHA:AES128-SHA:AES256-SHA

但有些客户端似乎会产生相同的“SSL 握手失败”错误。我想是因为配置太严格了。

【讨论】：

【解决方案3】：

这听起来像是在握手中途离开的客户端（TCP RST 或超时）。这在某种程度上是正常的，但 5-10% 听起来太高了。可能是证书问题；我不确定这到底是如何呈现给

发生在我身上的事情：

如果协商非常缓慢，将会有更多的客户流失。
您可能有潜在的 TCP 问题，直到您的新 SSL 端点代理开始报告这些问题时您才意识到这些问题。

您是否看到个别主机有时成功有时失败？如果是这样，这不太可能是证书问题。我不确定当用户拒绝不受信任的证书时连接是如何断开的。

您可以在 HAProxy 机器上使用 Wireshark 来捕获 SSL 握手并解析它们（您不需要解密会话以进行握手分析，尽管您可以使用服务器私钥）。

【讨论】：

感谢蒂姆非常彻底的回复。实际上，这正是您的第一个假设，因此我将在此处发布详细信息，以防有人遇到类似问题。我们使用这个后端服务于许多在关闭时发送分析数据的 Android 应用程序。有时（通常在 Android 上，在 iOS 上较少）没有足够的时间来实际完成请求，并且应用程序将在 https 协商期间或之后立即被终止，从而导致由 HAProxy 标记的 BADREQ 请求。最终，我确实最终使用了 ssldump 并准确分析出了问题所在。