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

Would you please link to this supposedly slapdash reference implementation? Taking RFC6520 at face value, it seems fairly reasonable and not out of line with other existing heartbeat protocols.

I've not read as much as I would like on the IETF's involvement in this but as I read the situation, Theo has just hurled vitriol at them for specifying a completely reasonable feature that the openSSL team implemented incredibly poorly.




It's not a completely reasonable feature.

It's a feature that had a sensible use case in DTLS (datagram TLS, TLS not run over TCP). It's unclear as to whether the use case was best addressed at the TLS layer, whether it could have been specified as something run alongside TLS, or whether it was something that applications that cared about path MTU could have handled for themselves.

The TLS WG actively discussed whether Heartbeat had reasonable use cases in TCP TLS. Some people agreed, some disagreed. Nobody threatened a temper tantrum if the feature was added to TCP TLS. Therefore: the extension was specified for both TCP TLS --- which does not need extra path MTU discovery, and which already has a (somewhat crappy) keepalive feature --- and DTLS.

The larger problem is in treating TLS like a grab-bag of features for corner-case applications.


Okay, I definitely agree regarding crufty specs. The decision to include heartbeats could easily have left left it as a variant feature rather than core spec.

I still don't agree with the OpenSSL implementation being reference spec if you were refering to that as pygy_ pointed out. Unless the IETF released that code as an institution, I would consider it the same as any other 3rd party implementation - ie. not necessarily correct. How am I to know that the RFCs author wrote it unless I go digging? Why should I trust anything they wrote which may or may not have gone through any rigorous checking?

This isn't so much directed at you, tptacek (since your pedigree is well known), as it is the others bashing the IETF for implementation flaws - bash them for what they actually did and perhaps instead of getting angsty at the powers that be, try getting involved in projects like this if you believe they are so important.


Last line, can we make that 72 pt font and top of the page?

(HN feature request: soundbits.)

This whole approach to diluting ostensibly one of the most important standards is beyond unprofessional, it's an example of failures on many layers of meta.

I would really like to see a compelling alternative to keep TLS honest, perhaps with Convergence-like ideas and bare-bones level of features.

The problem is always adoption, corporate fear of change ($upportabiĀ£itĀ„) and endpoint adoption, but the threat of an alternative might be enough to scare the bejebus of the WG back to task.


The reference implementation is the code that ended up in OpenSSL.

It was actully included in OpenSSL before the RFC was published.

Both the RFC and the code were written by the same person (who denies planting the bug intentionally).


Was that code ever actually sanctioned by the IETF and included in their resources though? SSL had SSLREF but I've never seen (and didn't find anything just now) a similar thing for TLS.


I won't judge whether the heartbeat feature itself is reasonable or not. But the inclusion of a payload was unnecessary, and specifying that it has to be copied to the reply message is so useless as to defy description. "Flexibility" my ass. It's downright suspicious.


The payload is meant to let you distinguish responses to different Heartbeats, right? I'm no expert, but sounds reasonable enough. I could see a lower limit on max payload size, but could you please elaborate a more detailed explanation why it's unnecessary and useless?


Okay, that explains things a bit. Could be done with a fixed-size payload though. Also I understand that the flexible size is intended to help with MTU discovery, but I think that would be a separate thing from a heartbeat.


Why would you need to send multiple different heartbeats over one connection? It's for keeping the connection alive.


If you are using data-grams (i.e., UDP) you have no guarantees of ordering or delivery, so you have no way to determine which transmission the echo reply you just received corresponds to without a payload that is returned to you.

Now, a 64kbyte payload, that's unnecessary for simply making each packet unique. That size was likely chosen to allow for the path MTU discovery aspects.

One could argue, however, that "keepalive" and "path MTU discovery" should not have been commingled, but they were.


Ping manages the same thing by incrementing an integer. For example.


No, ICMP echo request packets have variable-length payloads, which the receiver copies into the echo response.


Not much more suspicious than ping(8)


I always assumed ping's payload was for detecting packet fragmentation/size limit issues and as a trivial mechanism for spotting things like packet corruption.




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

Search: