HostAPd-WPE. Even though it works with the current OpenSSL, it would benefit from an older version of OpenSSL that has heartbleed. See "Testing Heartbleed" at the bottom of the page: https://github.com/aircrack-ng/aircrack-ng/tree/master/patches/wpe/hostapd-wpe
In this case, we may need to have 2 versions of the tools (See https://github.com/aircrack-ng/aircrack-ng/commit/430ad28df861d1fe638646f51cdf468c5b8a3f61#diff-aec6cf8281af39bd2b455fadb9fcd3b4 ): one with the recent OpenSSL and one with the old one and old MD5 certs.

Freeradius may benefit from an older OpenSSL version but I would think even XP should still support the current setup.

Try to build with LibreSSL instead of OpenSSL. LibreSSL has TLS 1.0

Another workaround: edit /etc/ssl/openssl.cnf and change MinProtocol to TLSv1.0 (at the very end of the file, in the '[system_default_sect]'.

FYI Metasploit is also impacted. I fixed it in one library with https://github.com/rapid7/metasploit-framework/pull/12214 but others might be concerned too.
Same in wpscan: https://github.com/wpscanteam/wpscan/issues/1380#issuecomment-525755956

Hello Raphaël, the issue seems to still be open (TLS 1.0 and 1.1 is still disabled system-wide on Kali for OpenSSL which leads to false positives when using security tools against older targets).

According to https://tracker.debian.org/pkg/openssl, Debian testing (from which Kali is based if I'm correct) is currently on 1.1.1d-2, where the Debian patches which disables older versions is still present, according to https://salsa.debian.org/debian/openssl/blob/debian/openssl-1.1.1d-2/debian/patches/Set-systemwide-default-settings-for-libssl-users.patch.

I saw your discussion on this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875423 which was closed by the upgrade to 1.1.1-2. However, this only improved the documentation (see https://salsa.debian.org/debian/openssl/blob/debian/openssl-1.1.1d-2/debian/libssl1.1.NEWS) but TLS 1.0 and 1.1 are still disabled and this choice seems assumed by the maintainer.

I also saw your fork for Kali with an interesting commit to disable this patch from Debian: https://gitlab.com/kalilinux/packages/openssl/commit/53db08fd7598d4308a17cf3158489f40201da265

What are the next steps? Could I be useful in any way?

@cnotin In the mean time, we have added http://pkg.kali.org/pkg/unsafeopenssl to our repository. Thus my suggestion would be that applications that need to support old protocols use that library. Unfortunately, this is also unlikely to be a viable long term solution as this is just a fork of an old libssl and it will likely not get support for new security protocols. :-|

I really don't want to fork openssl compared to Debian and the change you pointed out was really a temporary change.

Thanks/merci @rhertzog for your answer!

Indeed the situation is complicated and I do not see any solution that would not add a maintenance burden...
Would forking openssl for Kali from Debian be really complicated and heavy to maintain? For now the only difference would be removing the Debian patch that sets the systemwide default security level. But you know better than me :)