Hacker News new | past | comments | ask | show | jobs | submit login

Presumably people want TLS heartbeats for TCP because, by default, on Linux, TCP keep alive doesn't kick in until the connection has been idle for 2 hours.

Why write a call to setsocketopt() when we can just reinvent new features?

It's worse than that. Keepalives are only really useful for (a) long-lived connections that (b) are expensive (usually: requiring manual intervention or renumbering) to reestablish.

Those parameters describe no connection made by browsers.

In other words: application-layer keepalives are only valuable to applications that already have the freedom to define their own truly application-layer keepalive anyways.

And that still leaves the question of why spec a payload (much less 64k "for flexibility") in a TCP heartbeat exchange.

Because it's the same heartbeat message used for DTLS, where the heartbeat and padding allows for variable-length probes with request and response having varying size.

That is understood, Tom. The question remains why spec the same for two distinct transport layer protocols.

[edit: actually I was under the impression that the payload addressed response order concerns in UDP.]

(It's Thomas). Because it would have made even less sense to define a TLS-specific heartbeat and a DTLS-specific heartbeat.

In the hierarchy of sensible TLS decisions, you have, from most to least reasonable:

1. Not adding new heartbeat extensions to DTLS or TLS.

2. Adding new heartbeat extensions to DTLS only.

3. Adding the same new heartbeat extensions to DTLS and TLS.

4. Adding two different new heartbeat extensions, one for DTLS and the other TLS.

Not that I'm disagreeing with you, but aren't SSL connections rather expensive to establish because of the public key encrypted key exchange? Ofcourse anno 2014 that doesn't matter, but the whole library seems a bit engineered for 1998 when establishing SSL was probably a pretty significant thing.

They should be regarded as expensive today, because key exchange is one of distinct parts of the attack surface of an SSL implementation. The less often this exchange is visible to eavesdroppers, the better.

Repeated TLS reconnections do not necessarily invoke the entire key exchange.

.. I don't think that's a very realistic concern, is it?

Aren't websockets ping/pong messages similar?

Websockets messages are happening two layers up from TLS.

IOW: totally worthless.

The penalty for security fails of useless features should be a slow, painful, humiliating death.

You still need them for UDP.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact