View Issue Details

IDProjectCategoryView StatusLast Update
0005158Kali LinuxFeature Requestspublic2021-07-07 14:55
Reporterrhertzog Assigned Torhertzog  
Status assignedResolutionopen 
Summary0005158: Support old ciphers and old crypto protocols in various tools

To increase the security of many tools, old (broken security-wise) crypto protocols have been dropped (or disabled by default) from OpenSSL and other libraries.

This is the case of SSLv2 for example (support dropped a long time ago) and TLSv1.0/TLSv1.1 is currently disabled by default (see MinProtocol in /etc/ssl/openssl.conf, change re-introduced in 1.1.1-2 see and former revert in 0004238).

In the context of a penetration testing distribution, this is problematic because it doesn't let you connect/inspect services using those old crypto protocols.

There are various ways to work-around this limitation:

  • the tool itself can use the OpenSSL API to re-enable support for things that are disabled by default
  • the tool can be built against an old version of OpenSSL still supporting the desired protocols (sslscan is an example of this, see 0000146, same for sslyze see 0002106).

So we should look into some ways to have an openssl package supporting as many of those old protocols as possible.

Additional Information

It would be nice to have a list of applications where we want to support old ciphers/crypto protocols:

  • nikto (see 0004372)
  • nmap (see 0004372)
  • please complete (leave a comment)

It would be nice to have a list of old ciphers/crypto protocols that we would like to see supported:

  • SSL 2.0
  • TLS 1.0
  • TLS 1.1


related to 0004372 closeddookie Nikto/Nmap unable to handsake with older SSL version 
related to 0004238 resolvedrhertzog FreeRADIUS-WPE fails due to OpenSSL update 
related to 0004495 closed Some functions of enum4linux are incompatible with recent versions of smbclient 




2018-12-14 15:54

reporter   ~0010109

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:
In this case, we may need to have 2 versions of the tools (See ): 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.



2019-03-31 07:33

reporter   ~0010470

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



2019-04-05 19:59

reporter   ~0010479

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]'.



2019-08-28 14:07

reporter   ~0010947

FYI Metasploit is also impacted. I fixed it in one library with but others might be concerned too.
Same in wpscan:



2019-12-03 22:43

reporter   ~0011563

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, 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

I saw your discussion on this bug: which was closed by the upgrade to 1.1.1-2. However, this only improved the documentation (see 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:

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



2019-12-05 10:08

administrator   ~0011581

@cnotin In the mean time, we have added 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.



2019-12-08 16:26

reporter   ~0011602

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 :)

Issue History

Date Modified Username Field Change
2018-12-14 10:55 rhertzog New Issue
2018-12-14 10:56 rhertzog Relationship added related to 0004372
2018-12-14 10:58 rhertzog Relationship added related to 0004238
2018-12-14 11:02 rhertzog Description Updated
2018-12-14 11:02 rhertzog Assigned To => rhertzog
2018-12-14 11:02 rhertzog Status new => assigned
2018-12-14 15:54 Mister_X Note Added: 0010109
2018-12-14 15:56 g0tmi1k Relationship added related to 0004495
2019-03-29 16:02 rhertzog Priority normal => high
2019-03-31 07:33 sp Note Added: 0010470
2019-04-05 19:59 Mister_X Note Added: 0010479
2019-08-28 14:07 cnotin Note Added: 0010947
2019-12-03 22:43 cnotin Note Added: 0011563
2019-12-05 10:08 rhertzog Note Added: 0011581
2019-12-08 16:26 cnotin Note Added: 0011602
2019-12-12 09:10 rhertzog Priority high => normal