While testing a system today I ran into a webserver that was shockingly still requesting/supporting TLSv1. While TLSv1 has been around for a long time, most browsers/clients will be configured to not attempt to negotiate TLSv1 or TLSv1.1. For end-users, this is great from a security standpoint but from a pentesting stand point, we may still need to interact with that system!
The system today caused errors with everything from OWASP ZAP to Nikto to even the CuRL utility! Luckily Parrot OS (and most other Linux systems) support configuration changes to allow the system and tools to still communicate with an old system running a TLSv1/TLSv1.1 webserver.
First off here were some of the errors I was getting while trying to interact with the system.
- ZAP - The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]
- CuRL - error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
- Nikto - No web server found on X.X.X.X:443 (This one was odd as the error was not particularly indicative of the underlying error)
- nmap - No clear error messages but nmap failed to really be able to determine anything about the website/webserver
Now before beginning; Obligatory disclaimer. WARNING: Following the next steps will lower the security of the system! It is HIGHLY recommended that these steps not be performed on a system that is used for sensitive operations such as logging into email, bank accounts, credit card providers, etc. These steps are meant to enable a dedicated penetration testing station to access older crypto systems. I take zero responsibility for any damages that come from following this guide!
Disclaimer out of the way, let's walk through how to configure OpenSSL to allow older TLS versions system wide first. On many Linux systems, the system wide OpenSSL configurations are usually stored in the openssl configuration file ( /etc/ssl/openssl.cnf on ParrotOS and many other Debian systems). Within this file, there is a section labeled '[system_default_sect]'. On the current version of Parrot OS, the systems settings will look like this:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
To allow the system to connect to order TLS modes, the settings can be changed to the following:
[system_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT
Save the changes and it should be noted that many command line tools are likely to start communicating with TLSv1 systems. Take a look at the difference in CuRL with the change versus after the change in the below screenshot (Top error is MinProtocol set to TLSv1.2 and the bottom is TLSv1; The self-signed cert is a completely different issue).
The above solved the issue for many of the command line and other system tools but firing up ZAP later presented the same issue even though other tools were working just fine. Turns out that ZAP, since it relies on JAVA, had it's own configuration parameters that take priority over the system level configuration. Getting ZAP to ignore TLSv1 was a two step process. The first step is changing JAVA's security configuration as well as enabling ZAP to use TLSv1.
Let's first set JAVA's security to support TLSv1. In Parrot, and many other Debian based systems, the JAVA security settings are configured in the file /etc/java-11-openjdk/security.java.security. Within this file, locate the configuration option labeled jdk.tls.disabledAlgorithms. One will notice that TLSv1 and TLSv1.1 are disabled by default.
To enable JAVA's support for TLSv1 and TLSv1.1, simply remove those two options from the line and save the changes. NOTE: Remember this will affect all applications that use JAVA on the system!
Now to get ZAP to scan a site utilizing TLSv1/TLSv1.1. With the JAVA changes saved, launch ZAP. Once ZAP launches, navigate to Tools -> Options.
Once the menu loads, scroll to the 'Network' section and then click on the 'Connection' option. Within this menu area, there will be a number of security protocols that can be selected. Notice that TLS 1 and TLS 1.1 won't currently be checked but can be selected by clicking the check box next to them.
Click okay and then begin scanning the TLSv1 enabled website!
As a final reminder, following these instructions will lower the security of a system. Penetration testing systems like Parrot and Kali shouldn't be used for normal daily tasks and the changes made in these instructions should be reverted once the need has passed!
