Heartbleed：有效负载和填充

Question

阅读RFC 6520 for Heartbeat之后，我留下了几个问题：

https://tools.ietf.org/html/rfc6520

具体来说，我不明白为什么心跳需要包含任意有效负载甚至填充。根据我的理解，心跳的目的是验证对方是否仍然在线路的另一端注意。

这些可变长度的自定义有效负载提供的固定请求和响应是什么？

E.g。

Alice: still alive?
Bob: still alive!

毕竟，FTP使用NOOP命令保持连接活动，这似乎工作正常。

Answer 1

（以下不是直接答案，而是在此突出显示有关Heartbleed的其他问题的相关评论。）

---

有一些论点反对协议设计允许任意限制 - 要么应该没有有效载荷（甚至是回声/心跳功能），要么小的有限/固定有效载荷是更好的设计。

来自accepted answer

中Is the heartbleed bug a manifestation of the classic buffer overflow exploit in C?的评论

  

（R ..）关于最后一个问题，我会说任何大的回应请求都是恶意的。它消耗服务器资源（带宽，这需要花钱）来做一些完全没用的事情。心跳操作确实没有正当理由支持任何长度但零

     

（Eric Lippert）如果API的设计者认为那么他们根本就不会允许缓冲区传递，所以很明显他们不相信。 必须有一些设计理由来支持回声功能;为什么它不是一个固定大小的4字节缓冲区，这对我来说似乎已经足够了，我不知道。

     

（R ..）..从安全的角度来看，没有人会认为支持任意回应请求是合理的。即使不是因为心脏溢出问题，也可能存在与对等体发送的内容具有这种控制相关的加密弱点;这似乎不太可能，但在没有强有力的理由支持[n echo]功能的情况下，加密系统不应该支持它。它应该尽可能简单。

Answer 2

事实上，RFC 6520

中存在此有效负载/填充的原因

来自文件：

  

用户可以使用新的HeartbeatRequest消息，      必须由具有HeartbeartResponse的同伴回答      立即。执行PMTU发现，HeartbeatRequest消息      包含填充可以用作探测包，如中所述      [RFC4821]。   

<小时/>   特别是在没有多次重传之后      接收相应的HeartbeatResponse消息      预期的有效载荷，DTLS连接应该终止。   

---

  收到HeartbeatRequest消息并发送消息时      如本文其他地方所述，不禁止HeartbeatResponse      文件，接收方必须发送相应的HeartbeatResponse      带有收到的有效载荷的精确副本的消息      HeartbeatRequest。

     

如果收到的HeartbeatResponse消息不包含预期的消息      有效载荷，必须静默丢弃消息。如果它确实包含      预期的有效载荷，必须停止重传定时器。

感谢HackerNews的pwg。那里也有一个很好的相关讨论。

Answer 3

虽然我不知道这个决定背后的确切动机，但它可能是由ping实用程序使用的ICMP echo请求数据包所激发的。在ICMP回应请求中，可以将任意数据有效负载附加到数据包，如果目标服务器可以访问并响应ping请求，则目标服务器将准确返回该有效负载。这可用于验证数据是否通过网络正确发送，并且有效负载在传输过程中未被破坏。