22.4 Heartbleed

In 2014, Google’s security team member Neel Mehta privately reported an implementation bug to OpenSSL’s developer team. The same bug was independently discovered by security engineers working for Codenomicon, a Finnish security company specialized in network security that was eventually acquired by Synopsys. Following its disclosure, Heartbleed was assigned the CVE number CVE-2014-0160.

At the time of Heartbleed’s disclosure, more than half a million web servers – about 17% of all web servers using TLS at that time – were believed to be vulnerable to the attack. More importantly, Heartbleed allowed attackers to steal the servers’ private keys.

The private key SKAlice of a TLS server is its long-term secret corresponding to the public key in the server’s certificate. If Eve manages to compromises Alice’s private key, this has grave consequences: Eve can impersonate Alice and decrypt any future communication between server Alice and her clients. If the private key was used to establish a shared secret in a previous TLS session, Eve can decrypt this earlier communication as well.

For this reason, the non-profit digital rights group Electronic Frontier Foundation, technology magazine Ars Technica, and the American cryptographer Bruce Schneier described the Heartbleed bug as catastrophic. Joseph Steinberg, the cybersecurity columnist at the American business magazine Forbes, wrote that Heartbleed might be ”the worst vulnerability found (at least in terms of its potential impact) since commercial traffic began to flow on the Internet.”

22.4.1 TLS Heartbeat extension

The name Heartbleed is a pun on the TLS Heartbeat extension proposed in 2012 in RFC 6520. The name alludes to the fact that the Heartbleed attack exploits an implementation bug accidentally introduced with the Heartbeat extension’s implementation into OpenSSL version 1.0.1.

The Heartbeat extension specifies a mechanism for testing whether the TLS peer is still active and, as a result, keep the TLS session alive without the need for costly session renegotiation.

The Heartbeat protocol runs on top of the TLS Record protocol and consists of two message types: HeartbeatRequest and HeartbeatResponse. At any time during an active TLS session, Alice and Bob can receive a HeartbeatRequest message and are expected to answer it with a corresponding HeartbeatResponse message.

The Heartbeat protocol allows the sender to verify that the TLS peer can be reached and is alive. If no HeartbeatResponse message is received after some amount of time, the sender of the HeartbeatRequest (whether Alice or Bob) may terminate the TLS session.

Listing 22.1 shows the data structure of the TLS Heartbeat message specified in RFC 6520. It consists of the message type, an arbitrary payload, and padding:

Listing 22.1: The HeartbeatMessage data structure

struct {
   HeartbeatMessageType type;
   uint16 payload_length;
   opaque payload[HeartbeatMessage.payload_length];
   opaque padding[padding_length];
} HeartbeatMessage;

RFC 6520 specifies that a HeartbeatMessage cannot be larger than 214 bytes or max˙fragment˙length when it is negotiated between Alice and Bob according to the specification in RFC 6066.

The type variable of the HeartbeatMessage data structure can be either heartbeat˙request or heartbeat˙response. Unsurprisingly, the payload˙length variable contains the size of the arbitrary payload; the length of the payload˙length variable itself is two bytes. If the TLS peer receives a Heartbeat message where payload˙length is too large, they must silently discard that message. Finally, padding contains at least 16 bytes of random content that must be ignored by the receiver.The receiver of a HeartbeatRequest message must reply with a HeartbeatResponse message that contains an exact copy of the payload in the received HeartbeatRequest. If HeartbeatResponse does not contain the expected payload, the receiving TLS peer terminates the TLS session.