2

Regarding the priority to upgrade servers, I want to confirm this, as I read in https://www.rfc-editor.org/rfc/rfc6520 chapter 3:

However, a HeartbeatRequest message SHOULD NOT be sent during
handshakes. If a handshake is initiated while a HeartbeatRequest is
still in flight, the sending peer MUST stop the DTLS retransmission
timer for it. The receiving peer SHOULD discard the message
silently, if it arrives during the handshake. In case of DTLS,
HeartbeatRequest messages from older epochs SHOULD be discarded.

Am I correct to think that, if a server only accepts SSL connections from known clients, no one else can exploit the bug during the handshake?

My understanding is that the message should be dropped and that the server does not answer.

Improve this question
1
  • 2
    Typically malware authors DO NOT care about the RFC. If the RFC says that the client should not request heartbeats during a handshake, this is just a nice hint to malware authors that there might be an exploit opportunity somewhere around here, by doing just that.
    – MattBianco
    Apr 10, 2014 at 11:52

1 Answer 1

Reset to default
4

Apparently, the affected versions of OpenSSL don't implement that "SHOULD": they honour heartbeat messages during the handshake. Yeah, OpenSSL should discard such messages until the handshake has been completed -- but it should also not return data bytes outside of its buffer, and yet it does.

Therefore, no, requiring a complete handshake with client authentication does not protect against the bug.

Improve this answer
2
  • Ok, maybe they should change SHOULD to MUST.. But thank you for your answer!
    – MatK
    Apr 9, 2014 at 13:37
  • @MatthiasKnoll that's a matter of semantics. The protocol clearly required it not to for obvious security purposes, and someone did not double check that condition.
    – jfa
    Apr 14, 2014 at 0:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .