【问题标题】:JMeter javax.net.ssl.SSLHandshakeException intermittentlyJMeter javax.net.ssl.SSLHandshakeException 间歇性
【发布时间】:2018-12-16 02:39:07
【问题描述】:

我们正在运行一个 JMeter 脚本,它将 json 数据发布到内部 https 端点。但是我们在运行脚本时会间歇性地收到 javax.net.ssl.SSLHandshakeException(大约 100 次调用中的 3 次)。

此问题与以下 SO 问题非常相似,但此处讨论的所有解决方案均不适用于我: javax.net.ssl.SSLHandshakeException: handshake_failure when using JMeter with SSL (JDK8)

我正在使用 JDK8 和最新的 JMeter 4.0 版。我打开了 ssl 调试,从 ClientHello 和 ServerHello 消息中,看起来服务器支持 TLS 1.2 和 JMeter 也支持的 TLS_RSA_WITH_AES_128_CBC_SHA 密码套件。

但我在 SSL 日志中看到以下失败的 JMeter 请求:

写入:TLSv1.2 握手,长度 = 64
阅读:TLSv1.2 警报,长度 = 2
RECV TLSv1.2 ALERT:致命,handshake_failure
%% 无效:[Session-17, TLS_RSA_WITH_AES_128_CBC_SHA]

我尝试了以下解决方案:
1. jre cacerts 新增服务器证书
2. 为不支持的密码下载本地策略 jar 并将它们复制到 jre lib 安全文件夹
3. 更新 JMeter 的 httpclient jar (4.5)
4.在JMeter配置中显式启用TLS 1.2

我使用 TestSSLServer 来测试我们服务器的 SSL 功能,它返回的是:
SSLv3:
服务器选择:强制执行服务器首选项
3--(密钥:RSA)RSA_WITH_RC4_128_SHA
3--(密钥:RSA)RSA_WITH_AES_128_CBC_SHA
3--(密钥:RSA)RSA_WITH_AES_256_CBC_SHA
3--(密钥:RSA)RSA_WITH_3DES_EDE_CBC_SHA
TLSv1.0:同上
TLSv1.2:
服务器选择:强制执行服务器首选项
3--(密钥:RSA)RSA_WITH_RC4_128_SHA
3--(密钥:RSA)RSA_WITH_AES_128_CBC_SHA
3--(密钥:RSA)RSA_WITH_AES_256_CBC_SHA
3--(密钥:RSA)RSA_WITH_3DES_EDE_CBC_SHA
3--(密钥:RSA)RSA_WITH_AES_128_CBC_SHA256
3--(密钥:RSA)RSA_WITH_AES_256_CBC_SHA256

关于可能出现什么问题的任何想法?

【问题讨论】:

  • 目前为止的最佳选择,查看服务器日志以了解问题所在,然后进行调查并解决问题。否则设置 sysprop javax.net.debug=ssl 并保存将是巨大的输出(您可能需要购买更多磁盘)并花费数天或数周的时间来研究它。当服务器接受 AES128 时,您的 1 和 4 永远不会导致此警报,而您的 2 则不会。 (注意接受不等于要求;你的“期望”是模棱两可的。)
  • 感谢您的回复。我用 TestSSLServer 的结果编辑了这个问题,看起来 RSA_WITH_AES_128_CBC_SHA 是服务器的偏好之一。实际上,我在服务器端没有太多的控制权来调试东西。我想知道故障出在哪里,在客户端还是在服务器端。

标签: java ssl jmeter sslhandshakeexception f5


【解决方案1】:

这是 bug id 563488 中记录的已知问题,适用于早于 13.0 的 BIG-IP 版本,如 K34019109 中所述。

【讨论】:

    【解决方案2】:

    我无法真正找出确切的原因,但现在知道可能出了什么问题。按照 Dave 的建议,我打开了 SSL 调试并查看了所有日志,并将失败的请求与成功的请求进行了比较。

    对于失败的请求,这是我在日志中看到的:

    1. 客户端发送你好,服务器发送你好
    2. 服务器发送证书 & Server Hello Done
    3. 客户端密钥交换和更改密码规范
    4. 完成
    5. 此处失败,服务器没有更改密码消息,handshake_failure 错误

    如您所见,服务器由于某种原因无法响应。经过一番谷歌搜索后,我偶然发现了以下有关 f5 SSL 问题的论坛。我们的服务也通过 f5。我无法确认,因为我对我们的服务器端没有太多控制权,但下面的问题看起来很相似:

    https://devcentral.f5.com/questions/big-ip-proxy-ssl-121-handshake-failure-47464

    【讨论】:

    • 我们在 F5 ProxySSL 上遇到了非常相似的问题,它破坏了扩展的主密钥扩展。在服务器上禁用是我们的解决方案。此外,你没有在你的问题中提到这个代理元素(f5)。
    • 是的,之前并没有想到它可能与 f5 相关,但在查看 SSL 日志和一些搜索之后,这是有道理的。我想我应该将此标记为答案。
    • Java 的最新版本(8u161 和 9.0.4)确实支持 ExtendedMasterSecret,但他们(会)在每次握手时都使用它,不会断断续续。仅供参考,最近的 Java 版本不再需要无限策略的 jarever;他们终于消除了几十年前的错误特征。祝你好运。
    • 更新。我们的服务器团队告诉我们,他们已经解决了 f5 SSL 设置的问题,并表示当相同的 IP 连续访问服务时,这是一个边缘情况。我现在没有太多详细信息,但一旦我会在这里发布。感谢您帮助 Dave 和 Eugène。
    • 另一个更新。这个问题已被解决。我们的服务器团队对 f5 的设置方式进行了一些更改(我仍然没有具体细节),我们运行了 JMeter 自动化,我们不再看到 SSL 握手异常:)
    猜你喜欢
    • 1970-01-01
    • 2021-07-15
    • 2012-10-20
    • 2019-01-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-04-18
    • 2011-10-21
    相关资源
    最近更新 更多