View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005158||Kali Linux||Feature Requests||public||2018-12-14 10:55||2021-07-07 14:55|
|Summary||0005158: 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 https://tracker.debian.org/news/998835/accepted-openssl-111-2-source-into-unstable/ 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:
So we should look into some ways to have an openssl package supporting as many of those old protocols as possible.
It would be nice to have a list of applications where we want to support old ciphers/crypto protocols:
It would be nice to have a list of old ciphers/crypto protocols that we would like to see supported:
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
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.
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...
|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|