Remove heartbeats #1669
Remove heartbeats #1669
Conversation
The public API still exists, but doesn't do anything any more.
|
So it has a merge conflict. |
levitte
force-pushed
the
remove-heartbeats
branch
from
2efa5ca
to
59db14e
Compare
|
Not any more |
|
I'm curious why the previous state of affairs with DTLS-only heartbeats was deemed to be undesirable in preference of no heartbeat support at all. |
|
@kaduk, I'm afraid I don't understand your question... Mind you, I haven't been part of the heartbeats thing from the start, I'm just acting on an expressed desire to remove the heartbeats feature from OpenSSL. |
|
Concern that someone, somewhere was using it. |
|
I also don't see why this is on the agenda. If we don't trust the buffer management in 1.1.0 and master, we need to fix that, removing heartbeats from DTLS is solving yesterday's problem. It seems to me that DTLS heartbeats are a plausibly useful feature, for which we should be able to provide a correct implementation. |
|
They are perhaps theoretically useful, but nobody is using it as far as we can tell. |
|
There is very little DTLS use period. But if we are supporting it, I think the right posture is to proudly say that heartbleed is not a problem because our code is a lot more solid and we stand behind the implementation, than to remove it. We have cleaner buffer management, fuzzers, code review, ... it is I think time to stop paying attention to heartbleed and solve real problems. |
|
There’s an emotional aspect here as well. KILL IT |
|
The emotional aspect is irrelevant. If DTLS heartbeats remain in TLS 1.3, then we should continue to support the feature. Only if TLS 1.3 is removing DTLS heartbeats, then I could be talked into this on account of upcoming obsolescence.. |
|
We're not proudly supporting it - the test is thoroughly broken, nobody external has even noticed that, and nobody in the team has stepped up to fix it. |
|
Thanks for all the discussion. The test being broken and no one having noticed that does seem to give support to the belief that it is unused. Maybe some of that information could go in the commit message, though? |
|
My recollection is that even the ASA/AnyConnect that uses DTLS does not use Heartbeats; a data packet is used so that the VPN layer can "see" the keepalive/heartbeat. |
richsalz
added
the
approval: done
|
do the appropriate merge. finally. |
|
closed by mistake. |
|
@dwmw2: Do you have any comments about the usefulness of heartbeat for PMTUD in case of DTLS? |
|
@tmshort is correct; AnyConnect does it all at the data layer, using a one-byte packet type as the first byte of the payload. We do extend the protocol somewhat in OpenConnect (allowing standard DTLS, AEAD ciphersuites, proper negotiation, etc.) but we hadn't gone as far as using heartbeats to replace the Dead Peer Detection and keepalive, even though I suppose an argument could be made for doing so and regaining that byte. So MTU detection is done with large DPD payload packets, and we have no current plan to change that. And Cisco themselves have it implemented in hardware and don't even seem to have plans to catch up to DTLSv1.0 let alone change anything else. |
|
ping @levitte you want me to do this? My delete key is ready 👍 |
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from #1669)
|
@levitte, the first commit is merged. if you want to rebase or close or make a new one (or want me to do it) that holds only the second commit, which would be on-hold, let me know. |
|
Whatever I have to do, I'll do tomorrow. |
|
Can I request that the commit message say something about why the code is being removed? |
Oops, apparently I can't, because the commit was pushed already even though the PR is not closed. |
|
Too late now. And it should be immediately obvious to everyone about openssl and heartbeats. |
|
It is possible to add a note... |
|
Sure. But we don’t justify any other commits. |
|
It seems this PR was a bit too confusing. Question: do we want the "almost entire" removal in the 1.1.0 branch as well? That was my original intent. If we do, I'll prepare a separate PR for that. Meanwhile, this is now entirely merged into master. |
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from #1669)
|
No...we should not remove this from a stable branch. |
|
Ok then. Thank you. |
|
Doesn’t that change the API? Senior Architect, Akamai Technologies From: Richard Levitte [mailto:notifications@github.com] It seems this PR was a bit too confusing. Question: do we want the "almost entire" removal in the 1.1.0 branch as well? That was my original intent. If we do, I'll prepare a separate PR for that. Meanwhile, this is now entirely merged into master. — |
|
Errr... ah, you mean we finally got to the point where we need to create the OpenSSL_1_1_x branch? |
|
Actually, no... or, well, we could add back the |
|
Well, technically, this would be an ABI/API break so isn't eligible for 1.1.1, it would have to be 1.2.0 |
|
Keep the configuration interface the same. As a followup to my previous comment, The Cisco ASA was immune to Heartbleed because it didn't recognize the heartbeat record type. What happens now if a malicious client decides to send a heartbeat? Does the connection close, I presume? |
|
As of 1.1.0c (commit 436a2a0) any unrecognised record type results in the connection closing. |
|
You have to revert that "completely remove" commit. Source code that worked in 1.1.0 no longer works, configuration scripts no longer work (we talked about this with #1814 ), and binaries that used to work will probably now break. +1 to revert that change, and then put this rest of this MR on hold. |
|
I'll revert and make a new PR for pending 1.2.0 changes. I'm pretty sure those will start piling up and we might be ready for a 1.1.x branch. |
|
Reverted |
|
Yes, that is exactly the right thing. HEARTBEAT functionality was removed, but the API and compatibility with 1.1.0 was not changed. |
|
@FdaSilvaYY, I've kept the complete removal in a separate PR, #1928 |
Note: there are two commits. One removes heartbeats enough without changing the public API and is suitable to merge into OpenSSL_1_1_0-stable and master. The other one removes the heartbeats API entirely, and is more suitable for 1.2.0, whenever we get there.