4 ms·

"Removal of all heartbeat functionality which resulted in Heartbleed" Instead of simply fixing the bug and moving on, we're decided to assume the whole thing i

"Removal of all heartbeat functionality which resulted in Heartbleed" Instead of simply fixing the bug and moving on, we're decided to assume the whole thing is tainted and burn it alive like a depressed teenager at the salem witch trials? or is the heartbeat and IETF RFC considered suspicious and the heartbeat extension offers us nothing?

kansface 13y ago
It probably isn't needed by 99.999% of users. It should not have been added.
yuhong 13y ago
I think it can be added back if needed after the code is properly reviewed.
brubaker 13y ago
No it means a comprehensive code review that fixes all the ugly shit openssl devs have put in. It's a crap codebase and probably a tough call to not just destroy outright and start fresh.
jerf 13y ago
In addition to kansface's point, I'd observe it's a very recent addition. We made it a long way without it. There's a quote referenced so often it has become a cliche: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." by Antoine de Saint-Exupery. I think it's sometimes over-applied, but in the case of crypto software, it really fits. In a sense, the heartbeat code got unlucky and hit the mega-anti-jackpot, disproportional to its "actual" risk... but there was risk in adding it, and even before we know the outcome it would have, somebody really should have been asking hard questions about whether the reward justified the risk. I imagine there's a lot of other bits of the code where the risk/reward tradeoff suggests removal. You can look at much of what has already been trashed from that point of view. For instance, if you have no real need to support a particular defunct architecture, why carry around its code? It has no benefit, but non-zero risk; toast it.
- colechristensen 13y ago
  An good engineer's time should be spent more on taking away than on adding.
  - cls59 13y ago
    I think Colin Percival put it best in his blog post about Heartbleed: "The most secure code in the world is code which is never written; the least secure code is code which is written in order to comply with a requirement on page 70 of a 100-page standard, but never gets tested because nobody enables that option."
pipeep 13y ago
It's the wrong abstraction layer for a heartbeat signal. That can easily be done by the application if it's needed. TLS and DTLS should provide encryption wrappers for TCP and UDP. That's it. Sure, it's convenient to have it already available for you to use as an application developer, but critical security software needs to be kept as small and simple as possible.
AnthonyMouse 13y ago
> or is the heartbeat and IETF RFC considered suspicious and the heartbeat extension offers us nothing? The heartbeat extension is classic protocol bloat. In theory it can be useful for DTLS as a keep-alive for NAT port mappings or to do PMTU discovery, but you can do either one without it fairly easily. And then they went and added it to traditional non-datagram TLS where it serves the traditional screen door:submarine relationship.
lugg 13y ago
The beauty of open source is that you dont need to worry about silly things like productivity and return on time invested if you dont want to. The code is a mess from what I hear. As long as they keep the functionality intact I dont really think anyone can complain. I was quietly just thinking... Man I've gone to some lengths to force a rewrite in the past but this just takes it to a whole new level.

kansface 13y ago

It probably isn't needed by 99.999% of users. It should not have been added.

yuhong 13y ago

I think it can be added back if needed after the code is properly reviewed.

brubaker 13y ago

No it means a comprehensive code review that fixes all the ugly shit openssl devs have put in. It's a crap codebase and probably a tough call to not just destroy outright and start fresh.

jerf 13y ago

In addition to kansface's point, I'd observe it's a very recent addition. We made it a long way without it. There's a quote referenced so often it has become a cliche: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." by Antoine de Saint-Exupery. I think it's sometimes over-applied, but in the case of crypto software, it really fits. In a sense, the heartbeat code got unlucky and hit the mega-anti-jackpot, disproportional to its "actual" risk... but there was risk in adding it, and even before we know the outcome it would have, somebody really should have been asking hard questions about whether the reward justified the risk. I imagine there's a lot of other bits of the code where the risk/reward tradeoff suggests removal. You can look at much of what has already been trashed from that point of view. For instance, if you have no real need to support a particular defunct architecture, why carry around its code? It has no benefit, but non-zero risk; toast it.

colechristensen 13y ago
An good engineer's time should be spent more on taking away than on adding.
- cls59 13y ago
  I think Colin Percival put it best in his blog post about Heartbleed: "The most secure code in the world is code which is never written; the least secure code is code which is written in order to comply with a requirement on page 70 of a 100-page standard, but never gets tested because nobody enables that option."

pipeep 13y ago

It's the wrong abstraction layer for a heartbeat signal. That can easily be done by the application if it's needed. TLS and DTLS should provide encryption wrappers for TCP and UDP. That's it. Sure, it's convenient to have it already available for you to use as an application developer, but critical security software needs to be kept as small and simple as possible.

AnthonyMouse 13y ago

> or is the heartbeat and IETF RFC considered suspicious and the heartbeat extension offers us nothing? The heartbeat extension is classic protocol bloat. In theory it can be useful for DTLS as a keep-alive for NAT port mappings or to do PMTU discovery, but you can do either one without it fairly easily. And then they went and added it to traditional non-datagram TLS where it serves the traditional screen door:submarine relationship.

lugg 13y ago

The beauty of open source is that you dont need to worry about silly things like productivity and return on time invested if you dont want to. The code is a mess from what I hear. As long as they keep the functionality intact I dont really think anyone can complain. I was quietly just thinking... Man I've gone to some lengths to force a rewrite in the past but this just takes it to a whole new level.