Just want to highlight one more issue with using the original extension, many network security devices have threat signatures to identify the heartbeat extension in packet streams and they will block the sessions that match the signatures.
On Thu, Oct 21, 2021 at 7:31 AM Hanno Böck <ha...@hboeck.de> wrote: > On Thu, 21 Oct 2021 10:35:54 +0100 > Thomas Fossati <tho.i...@gmail.com> wrote: > > > One problem is - as Hannes put it - that heartbeat has a "somewhat > > tricky history", making its marketing a slightly intricate operation, > > and the code reuse story a bit more complicated than desired (see for > > example [3]). > > I think there were a few things that went spectacularly wrong with the > original heartbeat extension. Some of them are implementation issues > (like merging code without proper review and testing), but others are in > the spec itself. > > I think this boils down to two things that added unnecessary > complexity, which is always bad in security: > 1. The use cases were all UDP, but the extension was defined for both > UDP and TCP for no good reason. > 2. The extension contained a completely unnecessary length-encoded > message that was sent forth and back. That's a very risky > construction in terms of memory safety. > > I feel this may be enough justification to define a hearbeat-simplified > spec that doesn't have these problems. > If you decide to go with the old heartbeat extension then I'd still > wish you at least adress 1. I think many people have just compiled > openssl without heartbeat, which is a good thing as long as it's not > used anyway. If it gets used in DTLS then at least make sure that > doesn't mean it also has to be enabled in TCP-based normal TLS at the > same time. > > -- > Hanno Böck > https://hboeck.de/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
