【问题标题】:How to debug and fix intermittent SSL 'connection reset by peer' error?如何调试和修复间歇性 SSL 'connection reset by peer' 错误?
【发布时间】:2016-08-22 09:36:34
【问题描述】:

当通过 HTTPS 连接到服务器 (Windows/IIS) 时,我们的客户端 (CentOS) 上偶尔会出现(100 分之一)错误。

错误是:SSL: Connection reset by peer

运行 openssl s_client -connect example.com:443 -prexit 在 99% 的时间都有效,但有时会返回 write:errno=104,确认连接重置问题。

有趣的是,当连接重置并失败时,握手的大小不同(较小),但我看不到如何实际看到握手。

成功的连接是:SSL handshake has read 5308 bytes and written 319 bytes

一个失败的连接是:SSL handshake has read 5249 bytes and written 198 bytes

始终使用相同的协议 (TLS) 和密码。

服务器端,Windows事件日志中的错误是:A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 20. The Windows SChannel error state is 960.

致命错误代码 20 是 Received a record with an incorrect MAC. This message is always fatal.

任何人都可以帮助进一步调试吗?由于这只是一个偶然的问题,我很难思考为什么会发生这种情况。谢谢!

【问题讨论】:

  • 很可能由于没有满足服务器标准的证书,客户端没有提供请求的证书。但是,如果没有证据,这只是猜测,您的问题原则上是无法回答的。
  • 这样的场景不会一直重现吗?
  • 我记得这方面的两个勘误项。首先,旧版本的 OpenSSL 有时会产生 Bad MAC。我认为它是 OpenSSL 1.0.1,我希望它会在几乎所有客户端上得到修补。其次,我似乎记得 Diffie-Hellman 格式存在问题。另见Diffie-Hellman: value of Z - the shared secret - without leading zero octets。我不记得 IIS 是否遇到过 DH 问题,但我知道它偶尔会出现(比如 128 次中的 1 次)。

标签: ssl openssl ssl-certificate


【解决方案1】:

不是应用程序错误,但很可能是基础架构中的低级错误。不是特定于 SSL 而是面向连接的套接字。数据包 TTL 到期、网络路由更改或许多其他问题。编写良好的套接字代码总是会在失败之前重试几次。这很难调试,因为它通常不能在短时间内重复。

很多年前,这个错误让我发疯。我尽我所能追踪它,甚至编写了一个监视器来遍历系统的网络图,以确保图的每个节点都正常运行并正确响应。大约一年后,更换子网上的交换机后,问题就消失了。开关靠近应用程序而不是数据中心图表上的节点。

【讨论】:

    猜你喜欢
    • 2020-01-15
    • 2018-10-15
    • 1970-01-01
    • 1970-01-01
    • 2019-02-02
    • 1970-01-01
    • 2012-07-15
    • 2019-06-11
    • 1970-01-01
    相关资源
    最近更新 更多