为什么在启动 TLS 会话后服务器会进行 FIN？

Question

TLS 服务器正在做一些我无法理解的事情。

1. TCP 握手正常执行。
2. SSL Client Hello 正常执行。
3. SSL Server Hello 似乎正常。提供证书，显示 Server Hello Done。
4. 剖析显示客户端问题“客户端密钥交换、更改密码规范、加密握手消息”
5. 剖析显示服务器问题“更改密码规范”，然后是“加密握手消息”

客户端现在确认并开始发送数据。但服务器确认后会发送“加密警报”并发出 FIN。

交换证书后就发生了这种情况。SSL 握手中提供的证书是新密钥。

有人能提供线索吗？

Answer 1

这可能是由于客户端或中间设备（如负载平衡器）的 SNI 问题造成的。负载平衡设备必须能够将服务器名称作为初始客户端问候的一部分呈现给后端主机。请参阅https://en.m.wikipedia.org/wiki/Server_Name_Indication

Answer 2

最重要的数据包是“加密警报”，因为它包含关闭连接的原因。

这似乎是验证错误。这意味着证书不受信任或无效。但真正的原因是通过TLS 警报协议

Answer 3

pure-ftpd我在显式 TLS 模式（FTPS 服务器）中遇到了类似的问题。

但就我而言，不 Encrypted Alert从服务器发送；密钥交换后立即完成（Change Cipher Spec, Finished来自服务器的消息 → 来自服务器的 FIN）。接下来，客户端发送了Encrypted alert1 级代码 0 Close Notify（这是预期的 — 与服务器 FIN 不同）。

这只发生在一个特定客户端（设备固件）上，并且没有在其他 ftps 客户端上重现。

我还没有找到问题的根源，但我怀疑我们遇到了一个服务器错误.pure-ftpd使用类似 Apache 的 fork-per-connection 模型；我观察到子进程崩溃在 gdb 中（以代码 -1 退出）——这当然会导致操作系统关闭套接字 FD 并发送 FIN。

在我的案例中，还有一个原因可以说它是一个服务器错误——当我们将 ftps 服务器换成不同的实现时，这种行为就停止重现proftpd。

---

我认为这与 OP 的情况不符 — — 在那里，服务器以适合 TLS 的方式结束连接，并使用加密警报 — — 但尽管如此，任何访问此页面的人都应考虑这一点。