阅读 RFC 6520 for Heartbeat 后,我有几个问题:
https://www.rfc-editor.org/rfc/rfc6520
具体来说,我不明白为什么心跳需要包含任意有效负载甚至填充。据我了解,心跳的目的是验证对方是否还在线路的另一端关注。
这些可变长度的自定义有效负载提供了固定请求和响应所没有的什么?
例如
Alice: still alive?
Bob: still alive!
毕竟,FTP 使用 NOOP 命令来保持连接处于活动状态,这似乎工作正常。
阅读 RFC 6520 for Heartbeat 后,我有几个问题:
https://www.rfc-editor.org/rfc/rfc6520
具体来说,我不明白为什么心跳需要包含任意有效负载甚至填充。据我了解,心跳的目的是验证对方是否还在线路的另一端关注。
这些可变长度的自定义有效负载提供了固定请求和响应所没有的什么?
例如
Alice: still alive?
Bob: still alive!
毕竟,FTP 使用 NOOP 命令来保持连接处于活动状态,这似乎工作正常。
(以下不是直接回答,而是为了突出关于 Heartbleed 的另一个问题的相关评论。)
有反对协议设计允许任意限制的论点 - 要么不应该有有效载荷(甚至是回声/心跳功能),要么小的有限/固定有效载荷会是更好的设计。
从对已接受答案的评论中,Heartbleed bug 是 C 中经典缓冲区溢出漏洞利用的表现吗?
(R..)关于最后一个问题,我想说任何大的回声请求都是恶意的。它消耗服务器资源(带宽,这需要花钱)来做一些完全无用的事情。心跳操作确实没有正当理由支持除零以外的任何长度
(Eric Lippert) 如果 API 的设计者相信他们根本不会允许传递缓冲区,那么显然他们不相信。必须有一些设计上的理由来支持回声功能;为什么它不是一个固定大小的 4 字节缓冲区,这对我来说似乎足够了,我不知道。
(R..) .. 从安全的角度考虑,没有人会认为支持任意回显请求是合理的。即使不是因为心脏出血溢出问题,也可能存在与对对等方发送的内容进行此类控制相关的加密弱点;这似乎不太可能,但在没有充分理由支持 [n echo] 功能的情况下,密码系统不应该支持它。它应该尽可能简单。
从文件:
用户可以使用新的 HeartbeatRequest 消息,该消息必须由对等方立即使用 HeartbeartResponse 来回答。为了执行 PMTU 发现,包含填充的 HeartbeatRequest 消息可以用作探测数据包,如 [RFC4821]中所述。
如果收到的 HeartbeatResponse 消息不包含预期的有效负载,则必须静默丢弃该消息。如果它确实包含预期的有效载荷,则必须停止重传计时器。
归功于 HackerNews的pwg。那里也有很好的相关讨论。
虽然我不知道这个决定背后的确切动机,但它可能是由ping实用程序使用的 ICMP 回显请求数据包引起的。在 ICMP 回显请求中,可以将任意数据负载附加到数据包,如果目标服务器可访问并响应 ping 请求,则目标服务器将准确返回该负载。这可用于验证数据是否通过网络正确发送,并且有效负载在传输过程中没有损坏。