3 ms·

* T-Systems was never state-owned. The German Federal Post used to be state owned but was split into separate post, communications and banking divisions in 1995

* T-Systems was never state-owned. The German Federal Post used to be state owned but was split into separate post, communications and banking divisions in 1995. Deutsche Telekom IPO'd in 1996. T-Systems was founded in 2000 as a subsidiary of Deutsche Telekom. The German state currently holds around 15% of Deutsche Telekom stock. * RFC 6520 was published in February 2012. At that time Robin Seggelmann wasn't employed by T-Systems but was instead writing his dissertation at the University of Duisburg-Essen [1]. * His dissertation [2] actually gives an explanation for the payload: "The payload of the HeartbeatRequest can be chosen by the implementation, for example simple sequence numbers or something more elaborate. The HeartbeatResponse must contain the same payload as the request it answers, which allows the requesting peer to verify it. This is necessary to distinguish expected responses from delayed ones of previous requests, which can occur because of the unreliable transport." [1] http://www.robin-seggelmann.de/ http://www.robin-seggelmann.de/ [2] http://duepublico.uni-duisburg-essen.de/servlets/DerivateServlet/Derivate-31696/dissertation.pdf http://duepublico.uni-duisburg-essen.de/servlets/DerivateSer...

EvanAnderson 13y ago
This is the first that I've had time to actually sit down and look at code, the RFC, etc, and I'm scratching my head. The rationale for the payload for DTLS (sent over UDP) is reasonable, but I'm scratching my head over why the payload is even there for TLS. I guess there's some logic in making the protocol the same irrespective of underlying transport, but the payload is completely redundant for reliable protocols, which will handle any retransmission or reordering automatically. Edit: Upon further (amateur and arguably ill-informed) reflection I'd argue that the heartbeat functionality shouldn't apply to TLS at all. It's needless complexity that can be handled by the underlying reliable transport. That doesn't change that the OpenSSL project clearly has code-quality issues, but it would have averted this particular fiasco, at least. I am dismayed that a security-oriented protocol isn't focused on minimalast design. That seems very backward to me.
- caf 13y ago
  It's easy to see why, without the benefit of hindsight, one might think that the minimal approach was to have the same extensions apply to both DTLS and TLS.
  - EvanAnderson 13y ago
    I don't know where to go look (mailing list archives? meeting minutes?) to find any discussion about this extension (I'm woefully ignorant of Internet standards processes), but it would certainly be nice to review that discussion. Given the rather dramatic differences that need to occur in a protocol designed to work over unreliable versus reliable transport, though, it seems like a bad idea to try to keep "parity" between DTLS and TLS. I can see how somebody might see it as "elegant" to do so, but I'd argue they're different animals solving different problems.
    - ralfd 13y ago
      Maybe the payload is used for a sequential id number?
- noselasd 13y ago
  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.
jameshart 13y ago
It seems odd to, in a security context, say "The payload of the HeartbeatRequest can be chosen by the implementation", giving a huge amount of freedom to implementers (apparently it was determined that "something more elaborate" might extend to an implementation needing to send a full 64K of chosen payload data) without further investigating whether any particular choices made by the implementation might have consequences for the security of the protocol. Why allow variable length payloads at all? Why allow more than about 128 bits of data for distinguishing responses? I guess you might argue a client might want to disguise the nature of these heartbeat packets from an eavesdropper, so they need to be variable in size - that's reasonable, but if it's a requirement, then surely you'd want to comment on the security risk of using a "simple sequence of numbers" rather than "something more elaborate". 64K of data, though? That seems like a lot of leeway to give an implementation - considerably more than enough to disambiguate heartbeat packets; implementations are going to keep 64K of data around and compare it byte for byte to check whether the echo they got back matches the payload they transmitted earlier? I really don't mean to ascribe malice here; I tend to assume this is just a bug, and that the payload for heartbeat packets gets to be up to 64K because once you've decided to make something a variable length buffer, you're probably choosing between having a one byte or a two byte field for length, and 256 bytes seems like it might be too small so you figure 'why not make the length field two bytes?' and then... oops; someone makes a buffer overrun and suddenly we're faced with 64K at a time of data being ripped out of any old server's heap.
- wiml 13y ago
  I wonder if it's simply that the DTLS heartbeat is modeled on the ICMP echo-request packet? Pings also contain a blob of up to 64kB of arbitrary data (in the case of ICMP, this is/was handy for detecting pattern-dependent link problems). Unlike DTLS, though, the length of the payload is determined by the enclosing protocol, not redundantly by a length field in the packet itself.

EvanAnderson 13y ago

This is the first that I've had time to actually sit down and look at code, the RFC, etc, and I'm scratching my head. The rationale for the payload for DTLS (sent over UDP) is reasonable, but I'm scratching my head over why the payload is even there for TLS. I guess there's some logic in making the protocol the same irrespective of underlying transport, but the payload is completely redundant for reliable protocols, which will handle any retransmission or reordering automatically. Edit: Upon further (amateur and arguably ill-informed) reflection I'd argue that the heartbeat functionality shouldn't apply to TLS at all. It's needless complexity that can be handled by the underlying reliable transport. That doesn't change that the OpenSSL project clearly has code-quality issues, but it would have averted this particular fiasco, at least. I am dismayed that a security-oriented protocol isn't focused on minimalast design. That seems very backward to me.

caf 13y ago
It's easy to see why, without the benefit of hindsight, one might think that the minimal approach was to have the same extensions apply to both DTLS and TLS.
- EvanAnderson 13y ago
  I don't know where to go look (mailing list archives? meeting minutes?) to find any discussion about this extension (I'm woefully ignorant of Internet standards processes), but it would certainly be nice to review that discussion. Given the rather dramatic differences that need to occur in a protocol designed to work over unreliable versus reliable transport, though, it seems like a bad idea to try to keep "parity" between DTLS and TLS. I can see how somebody might see it as "elegant" to do so, but I'd argue they're different animals solving different problems.
  - ralfd 13y ago
    Maybe the payload is used for a sequential id number?
noselasd 13y ago
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.

jameshart 13y ago

It seems odd to, in a security context, say "The payload of the HeartbeatRequest can be chosen by the implementation", giving a huge amount of freedom to implementers (apparently it was determined that "something more elaborate" might extend to an implementation needing to send a full 64K of chosen payload data) without further investigating whether any particular choices made by the implementation might have consequences for the security of the protocol. Why allow variable length payloads at all? Why allow more than about 128 bits of data for distinguishing responses? I guess you might argue a client might want to disguise the nature of these heartbeat packets from an eavesdropper, so they need to be variable in size - that's reasonable, but if it's a requirement, then surely you'd want to comment on the security risk of using a "simple sequence of numbers" rather than "something more elaborate". 64K of data, though? That seems like a lot of leeway to give an implementation - considerably more than enough to disambiguate heartbeat packets; implementations are going to keep 64K of data around and compare it byte for byte to check whether the echo they got back matches the payload they transmitted earlier? I really don't mean to ascribe malice here; I tend to assume this is just a bug, and that the payload for heartbeat packets gets to be up to 64K because once you've decided to make something a variable length buffer, you're probably choosing between having a one byte or a two byte field for length, and 256 bytes seems like it might be too small so you figure 'why not make the length field two bytes?' and then... oops; someone makes a buffer overrun and suddenly we're faced with 64K at a time of data being ripped out of any old server's heap.

wiml 13y ago
I wonder if it's simply that the DTLS heartbeat is modeled on the ICMP echo-request packet? Pings also contain a blob of up to 64kB of arbitrary data (in the case of ICMP, this is/was handy for detecting pattern-dependent link problems). Unlike DTLS, though, the length of the payload is determined by the enclosing protocol, not redundantly by a length field in the packet itself.