View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005158 | Kali Linux | [All Projects] Feature Requests | public | 2018-12-14 10:55 | 2021-07-07 14:55 |
| Reporter | rhertzog | Assigned To | rhertzog | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0005158: Support old ciphers and old crypto protocols in various tools | ||||
| Description | 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: - 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 | ||||
|
|
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 :) |
| 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 | View Revisions |
| 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 |