22

The heartbeat extension to the TLS protocol seems like a useful idea for DTLS; according to the specification itself, it can be used to find out if a peer is still alive (and prevent firewalls from dropping the connection) without a renegotiation and for path MTU discovery.

However, I don't understand the motivation for specifying and implementing it for regular, TCP-based TLS. Wouldn't sending empty application data fragments essentially solve the problem of stateful firewalls dropping idle connections as well?

The RFC for TLS explicitly allows that behavior:

Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.

Improve this question

3 Answers 3

Reset to default
15

The heartbeat serves two purposes: to make some link-level activity (to avoid closure by zealous firewalls) and to make sure that the peer is still alive. If you want to do both with empty fragments, then you need some convention between client and server, so that when you send an empty fragment, the peer responds with an empty fragment. This has potential for infinite loops if not done correctly.

Moreover, when empty fragments were used as a countermeasure to the BEAST attack, it appeared that some widely deployed implementations had trouble with them. This is why we do a "1/n-1 split", not a "0/n" split.

Thus, the heartbeat extension is mostly a formalization of that ping-like convention, with its own initial negotiation and format so that interoperability issues do not arise.

Improve this answer
2
  • 3
    Can you explain what is meant with the "1/n-1 split"?
    – SPRBRN
    Apr 9, 2014 at 12:45
  • 5
    Instead of sending a SSL record with n bytes of data, a client or server sends two records, the first one containing 1 byte, the second containing the remaining n-1 bytes. This allows for some "randomization" of the IV for CBC encryption, which defeats BEAST. Theoretically, a 0/n split would have worked, but at least IE 6.0 crashed on a zero-length record.
    – Tom Leek
    Apr 9, 2014 at 12:58
4

The principal benefit for a TLS based implementation is that the same SSL Record processing code can be used for TLS and DTLS. Otherwise your SSL Record processing code needs to known the underlying transport mechanism.

The other use for this is for multi-streamed reliable transport protocols, over which you have TLS. The example in the RFC is SCTP. In this case, there is some use.

The practical use of this over TCP is close to nil.

Improve this answer
1
  • For reference, RFC 6520 Section 1 states why a heartbeat extension is useful for DTLS: The only mechanism available at the DTLS layer to figure out if a peer is still alive is a costly renegotiation and DTLS needs to perform path MTU (PMTU) discovery but has no specific message type to realize it without affecting the transfer of user messages.
    – Lukas
    Apr 11, 2014 at 9:11
-4

TCP already has keepalives (and EVERY TCP connection must be guarded against "zealous firewalls" if this requirement exists), so re-keepaliving in SSL is useless.

Improve this answer
3
  • 3
    Please dive deeper into the reason its useless because its not useless otherwise hundreds of thousands of very smart people wouldn't have enabled it and it wouldn't have even been developed.
    – Ramhound
    Apr 11, 2014 at 4:43
  • SSL makes no assumptions on the underlying transport protocol. UDP, for instance, is unreliable and you might still want to implement SSL/TLS upon it. @Ramhound Wouldn't these hundreds of thousands of very smart people have been able to detect this exploit earlier? I mean not checking memory bounds is a greenhorn mistake.
    – Lukas
    Apr 11, 2014 at 10:02
  • @Lukas - It wasn't detected because the bug wasn't in every version of OpenSSL.
    – Ramhound
    Apr 11, 2014 at 11:08

You must log in to answer this question.

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