未等待peer的close_notify响应的风险及截断攻击原理问询

参考文档说明 #

应用程序可以仅发送关闭警报后就关闭底层连接，无需等待peer的响应。这样可以节省资源，因为进程可以立即终止或处理其他连接。仅当确定对方不会再发送更多数据时才可如此操作，否则存在截断攻击的风险。

攻击运作原理 #

截断攻击本质是攻击者冒充通信中的某一方，提前发送连接关闭信号，让另一方误以为通信已正常完成，从而忽略后续的合法数据传输。

在你描述的场景中：如果我方发送关闭警报后直接断开连接、不等待peer响应，攻击者就有可乘之机——它可以在peer还没发完所有合法数据时，伪造关闭信号或者直接阻断后续数据通路。此时我方会误以为通信已经结束，但实际上peer还有未传输完成的有效数据。

潜在损害场景 #

这种攻击的危害核心是让我方基于不完整的通信信息做出错误决策，举几个实际例子：

• 转账场景：peer（如支付服务器）已经发出“转账成功”的确认数据，但攻击者在该数据到达我方前截断了连接。我方因未收到确认，可能重复发起转账，造成资金损失。
• 文件传输场景：我方提前断开连接，误以为文件已接收完整，但最后一段有效数据被攻击者截断，导致文件损坏、校验失败；若为可执行文件，还可能被植入恶意片段（结合其他攻击手段）。
• API交互场景：peer返回的响应包含多个业务字段，攻击者截断了部分关键字段，我方基于不完整响应执行逻辑，会引发业务状态混乱，比如订单状态错误、权限校验失效等。

简言之，风险不在于我方没读取后续数据，而在于攻击者能让我方错误判定通信已正常结束，进而基于不完整信息触发错误的业务行为。正常情况下等待peer的关闭响应，能确保双方确认数据传输完毕，避免被冒充截断的风险。

内容的提问来源于stack exchange，提问作者Dragan