DTLS Heartbeat Removed in OpenSSL 1.1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

DTLS Heartbeat Removed in OpenSSL 1.1.1

vkaliape
Hello, 

From the release notes of OpenSSL 1.1.1, I could see that DTLS heartbeat has been removed
.  
Heartbeat support has been removed; the ABI is changed for now.  

With  RFC 6520 in standards track, any specific reason(Vulnerability/other security issue reported) for the removal ?,   How can we re-enable it ?  Recompile OpenSSL without OPENSSL_NO_HEARTBEATS macro ?   Please advise.

Regards,
Vijay 
Reply | Threaded
Open this post in threaded view
|

Re: DTLS Heartbeat Removed in OpenSSL 1.1.1

vkaliape
Hi, 

I am just following up with my earlier mail as I did not get an answer.   I now understand that the heartbeat mechanism is completely removed in OpenSSL 1.1.1,  whereas it's still available in gnuTLS.   So I do not understand why it was removed from OpenSSL
Having your own keepalive mechanism(at application level) the only way forward ?  I am still looking for some answers.    Can someone throw some light on it ?

Regards,
Vijay

On Tue, Jun 9, 2020 at 2:25 PM Vijayakumar Kaliaperumal <[hidden email]> wrote:
Hello, 

From the release notes of OpenSSL 1.1.1, I could see that DTLS heartbeat has been removed
.  
Heartbeat support has been removed; the ABI is changed for now.  

With  RFC 6520 in standards track, any specific reason(Vulnerability/other security issue reported) for the removal ?,   How can we re-enable it ?  Recompile OpenSSL without OPENSSL_NO_HEARTBEATS macro ?   Please advise.

Regards,
Vijay 
Reply | Threaded
Open this post in threaded view
|

RE: DTLS Heartbeat Removed in OpenSSL 1.1.1

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Vijayakumar Kaliaperumal
> Sent: Wednesday, July 08, 2020 11:32

> I now understand that the heartbeat mechanism is completely removed in OpenSSL
> 1.1.1, whereas it's still available in gnuTLS.

gnuTLS would not be my personal choice of exemplar. "gnuTLS does it" often seems to be a better argument against something than for it.

> So I do not understand why it was removed from OpenSSL

Well, PR 1928 (https://github.com/openssl/openssl/pull/1928), which removed it, doesn't have a lot of discussion. Richard Levitte created the changes and the request, and Tim Hudson approved them; there's not much else, aside from some comments regarding deprecating the Configure option (which I believe was done). The PR does mention Issue 4856 (https://github.com/openssl/openssl/issues/4856), in which Hanno Boeck cites Heartbleed and claims "there don't seem to be any real world use cases".

I'm not convinced that there aren't *any* real-world use cases. Your message suggests you have one, and Seggelmann et al. presumably had one when they wrote RFC 6520 and Seggelmann submitted the code change for OpenSSL. RFC 6520 notes that Heartbeat can be used for PMTU discovery for DTLS, besides its nominal "are you still there?" function. And keepalives are used in a number of protocols, both to keep a path active (though that was more relevant when virtual-circuit-switching and on-demand physical links were more common) and to periodically test a path to ensure the peer was still reachable and responding.

However, Hanno Boeck knows as much about real-world TLS and DTLS usage as anyone I can think of, and Heartbeat is widely viewed as over-engineered and unnecessarily complex, which is why we had Heartbleed in the first place. None of the products I currently work on use DTLS, but if they did, I wouldn't be sorry to see Heartbeat go.

> Having your own keepalive mechanism(at application level) the only way forward?

If you're using OpenSSL, then I'd say it's either implement one in the application, or create an intermediate library that adds a keepalive mechanism on top of OpenSSL's DTLS support, or hack Heartbeat back into OpenSSL. I definitely would not recommend the third. The first lets you tailor the keepalive to the application's architecture and needs; the second lets you reuse the implementation.

--
Michael Wojcik