2 ms·

If you ever implement connection oriented protocols, you will very quickly find the need for a heartbeat mechanism - otherwise you have no way of telling whethe

If you ever implement connection oriented protocols, you will very quickly find the need for a heartbeat mechanism - otherwise you have no way of telling whether the remote end is dead, or if is just busy creating data for you/doesn't have any data for you right now. Not having heartbeats, you end up relying only on arbitrary timers to time out your connections, which are far from optimal, or you end up relying only on the underlying protocol which is not enough in most cases. TCP doesn't provide that for you. (TCP does provide keepalives, intended for other means, they might be a poor mans substitute, but they arn't exposed to the TCP user in a particularly useful way - it's also the wrong layer for this problem)

EvanAnderson 13y ago
I'm familiar with the paradigm. I've written some code to talk to dodgy embedded devices that don't "talk" unless they have something to say and I have ended up having to use timers. It sucks, to be sure. I looked back to RFC1122 to get a feel for the nature of TCP keepalives, and I would agree that they're unsuitable for this application. If we posit that a keepalive mechanism is useful for TLS I'd still argue that a payload is unnecessary because TCP will handle in-order delivery. A NOOP with some random-length padding would have worked just as well.
rst 13y ago
TCP heartbeats certainly will let you know if the remote end is entirely dead. They won't let you know if the application process is jammed up --- but TLS hearbeats won't do that for you either! (For example, it's common to have the crypto handled by front-end processes, with the application logic elsewhere.) So if that's what you want, then you need heartbeats at the application layer, not in TLS. Given all that, the case for hearbeats at the TLS layer for TLS over TCP seems ... weak. Particularly since simply having them there violates the commonly cited best practice that security kernels should be kept small. And this violation has already had disastrous consequences. Besides, for all the times I see people making this argument, I've yet to see them cite an example of a real problem in a real world deployment for which TLS hearbeats were used, and turned out to be the best solution.

EvanAnderson 13y ago

I'm familiar with the paradigm. I've written some code to talk to dodgy embedded devices that don't "talk" unless they have something to say and I have ended up having to use timers. It sucks, to be sure. I looked back to RFC1122 to get a feel for the nature of TCP keepalives, and I would agree that they're unsuitable for this application. If we posit that a keepalive mechanism is useful for TLS I'd still argue that a payload is unnecessary because TCP will handle in-order delivery. A NOOP with some random-length padding would have worked just as well.

rst 13y ago

TCP heartbeats certainly will let you know if the remote end is entirely dead. They won't let you know if the application process is jammed up --- but TLS hearbeats won't do that for you either! (For example, it's common to have the crypto handled by front-end processes, with the application logic elsewhere.) So if that's what you want, then you need heartbeats at the application layer, not in TLS. Given all that, the case for hearbeats at the TLS layer for TLS over TCP seems ... weak. Particularly since simply having them there violates the commonly cited best practice that security kernels should be kept small. And this violation has already had disastrous consequences. Besides, for all the times I see people making this argument, I've yet to see them cite an example of a real problem in a real world deployment for which TLS hearbeats were used, and turned out to be the best solution.