<= Archives =>
Nine pages in 2.5 years
2014/04/24 21:33:20 CEST

A log message from de Raadt accompanying a Makefile change (see revision 1.29):

Log message: Disable Segglemann's RFC520 hearbeat.

I am completely blown away that the same IETF that cannot efficiently allocate needed protocol, service numbers, or other such things when they are needed, can so quickly and easily rubber stamp the addition of a 64K Covert Channel in a critical protocol. The organization should look at itself very carefully, find out how this this happened, and everyone who allowed this to happen on their watch should be evicted from the decision making process. IETF, I don't trust you.

It is in fact RFC 6520. According to IETF's Datatracker, the first draft was published in July 2009, there were two other drafts ([1]), then RFC 6520 in February 2012. It took 2 years and a half to go from draft to standard status.

Quoting the RFC:

When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest.

The second part of the sentence is critical – the peer must manipulate data and send back a copy. With the possible sizes of the payload, and repetitive requests, there is indeed room for a covert channel should the implementation screw it - which happened. The RFC is liberal, with peers being able to choose not to answer HeartbeatRequest messages, but the fact is this is not the default in OpenSSL.

[1] Not mentioning the five "ietf" drafts.

Tags security heartbleed