This is an article willing to help and point out a few useful resources for those using Apache HTTP or NGINX web servers that are still using the deprecated SSLv3, TLS 1.0 and/or TLS 1.1 verions.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
0.- The what and the why.
Believe it or not there are still millions of servers still using those deprecated versions of SSL and TLS protocols. Shodan.io has a report on this specific, it’s not me with a crystal ball. Just extract the 3.148.344 servers using the still supported TLS 1.2 from the total 7.170.224 found by Shodan.io and off we go. What are these servers? Probably, many of them, are corporate servers where administrators, developers and other IT creatures are trapped under the boot of burocracy and the alleged efficiency of very little technical staff and lots of management souls. Not even Ansible is capable of defeating that in any easy way.
However it came to be these are facts. During the last months I’ve personally observed many sites adopting a better posture towards security by securing their headers. Reputation is at stake when visitors to a site can be harmed. I included this bit in a couple of hardening guides, one for DOcean and the other for this very site of mine.
I am unsure of what are the main web browsers of this world (Chrome, Firefox, Edge, Safari) are doing in respect of flagging these old SSL/TLS versions on sites. One could argue doing nothing is good, since there’s still some encryption but my point is (and the one made by many others) that the use of deprecated and even vulnerable encryption can easily give a sense of false security.
For those using tools like Letsencrypt and the Certbot this article will make not much sense, unless… I’ve seen the certbot client configuring me the server to support TLS 1.0 and TLS 1.1 just a month ago, and those are well deprecated now. I don’t know if it did because my old configuration still supported those or if it’s still a default on the certbot tool.
Anyhow, let’s dig into this how to configure TLS 1.2 on UNIX or GNU/Linux.
First, we need to understand a few implications on changing this SSL/TLS configuration. Both parties, the server and the client must understand each other, so they must make use of cipher suites and protocol versions supported by both. An old browser will not be able to understand a modernly configured web server just serving content with TLS 1.3 (nor 1.2). There is another side also, such as a modern browser will not be able to work correctly with a server configured with old protocols. The coronavirus SARS-CoV-2 (known for COVID-19) made Firefox reverse their decision of deprecating the use of TLS 1.0 and 1.1 as it can be read here. But eventually the decision will be applied back.
Unfortunately for many, there are still many RHEL 5 boxes around, hidden and guarded by tall walls (firewalls). Some of those boxes are still in use and still provide good use for internal applications, and sometimes even (strangely) for external. How to upgrade those and make them use TLS 1.2? There is only one cheap way to do this. Put a proxy in between and make it modernly configured. Use the latest bits and pieces and point a gun to anyone’s head if they pretend to undermine its maintenance.
But can anyone configure a modern software piece such as Apache HTTP 2.4.43 to be used by an old browser supporting SSLv3? Yes, of course! Just remove the ‘-SSLv3’ in the next directive.
SSLProtocol all -SSLv3
Old boxes that shouldn’t be in your organization, but they are extremely necessary because the SCADA software they use can’t be put into Windows 10 and just works on XP, can make use of that modern server they also need to access. Just think about the crystal clear or muddy waters you will be navigating through and act accordingly.
2.- Configuration tools
How to configure TLS 1.2 can be a pain in the ass. It actually is. For this very reason the Mozilla folks, those you have massively betrayed by making Chrome the default browser in the Windows workstations inside your big corporation, have awesome documentation for the web. They have published a tool which allows you to choose a functional configuration, where you can determine the web server you are using, the client support you need to cover (dividied in three levels), and the openssl version you use. The tool can be found in the following link.
Down below a screen capture of a configuration provided by the tool.
As you can see in the next screen capture you can tune the configuration as you wish by choosing the server software, the configuration level of modern, intermediate or old, the environment by selection the web server and openssl versions and even two other parameters such as the HSTS header and the OCSP stappling.
You are maybe using NGINX and while you can (and I insist) configure that with the Mozilla’s tool, the friends at DigitalOcean have also made a similar tool available but just for NGINX. I wish the’d thought about Apache HTTP as well.
Once we’ve seen the implications and a couple of helpful tools so we don’t get mad at looking what specific cipher suite to add, because it’s terribly tedious and boring (and someone has already done it, so thanks!), we can talk about the key directives.
3.- Key directives
The key directives to modify what protocols are accepted in SSL/TLS negotiation are: ‘SSLProtocol’ for Apache HTTP and ‘ssl_protocols’ for NGINX. Modifications on these do also need cipher suite support adjustment. Assist yourself with the proposed configuration tools described above to get the best support for cipher suites and protocols combination.
In order to deny the support for SSLv3 one must add the minus sign in front of its declaration in the httpd.conf file in Apache HTTP. On the other hand NGINX only needs the accepted protocols to be declared in nginx.conf.
In Apache HTTP you can read things such as the following.
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
The location of this directive may be different depending on your environment. This is typically found in the main configuration file either named httpd.conf or apache2.conf, in turn depending of the kind of GNU/Linux system you are using. The file is usually inside the /etc directory. You may be using virtual hosts and fine tune this directive for each one instead.
On NGINX just declaring the accepted protocols suffices.
ssl_protocols TLSv1.2 TLSv1.3;
4.- The checks
To check the new directives are taking effect the openssl program with the s_client option can be used. From a UNIX/Linux terminal use the following combinations.
openssl s_client -connect example.com:443 -ssl3
openssl s_client -connect example.com:443 -tls1
openssl s_client -connect example.com:443 -tls1_1
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3
If the protocol version is not supported the result with show errors and the connection will not be stablished as shown in the example below.
On the contrary if the protocol version is supported the result will stablish a connection with the server. Just type enter and the connection will almost surely close. Very basic input can be put here. When the connection is stablished the certificate and keys are shared as the example below demonstrates.
5.- Testing performance
Be careful when testing performance on any application and be wary of doing that on a production environment. And don’t use these tools without authorization, specially to servers or sites out of your control. Take special consideration, at least, these two aspects for a more accurate testing.
– How far is the testing machine from the target. Since it is not always possible to hit a target from the same exact VLAN, at least try to launch these tools involving the lesser amount of network devices in between.
– The usual load the system has and what do you expect under normal (namely already existing) conditions.
Do also take in account your regular testing procedures, if you have any, and compare the results with your own metrics.
– Apache Bench
In order to test Apache one can use the benchmark tool already present (if the option is present at compile time or later installed), called AB.
To send 10 requests from 5 concurrent users:
ab -n 10 -c 5 http://www.example.com/
This is another benchmarking tool for web servers.
In order to test 50 concurrent users during 5 seconds use the following command.
siege -q -t 5S -c 50 http://www.example.com/
6.- Security quality testing tools
These tools may assist you in achieving a good configuration and testing your results. Remember to tick the “hiding results” boxes so no information is disclosed.
– Nmap. Nmap is often used as a pentest tool however it’s quite useful for testing purposes as well. If we want to test what protocols are enabled on a given target we can launch the nmap tool with elevated privileges on a UNIX/Linux system:
# nmap –script ssl-enum-ciphers -p 443 example.com | grep -E "TLSv|SSLv "
There is a GUI version for nmap and it’s also available for Windows. The same commands as in regular nmap can be used.
– SSL Labs. With this tool you can also fine tune the selection of cipher suites to allow, since it launches handshake simulations representing different types of devices using a plethora of operating systems, browsers and others such as Java or OpenSSL libraries.
Remember to tick the “Do not show the results on the boards” box.
– Security Headers. This tool will assist you in checking the security headers have been properly configured and show you a few of their values.
Remember to tick the “Do not show the results on the boards” box.
7.- Enable HTTP/2 whenever possible (extra recommendation).
Configure the web server to support HTTP/2 version instead of 1.1 so requests are fulfilled in a quicker fashion.
8.- Headers & Cookies (extra recommendation)
Although these seem to be more actively implemented lately, they are worth to mention. Securing headers and cookies will allow the connection between the server and the client to be more robust and secure. Applying this set will not improve the server’s security per se but it will help a lot in protecting the client side and therefore improving your site’s security and reliability. If confidence and trust is a basis for your online business make sure you apply these.
However if you happen to use NGINX this block of directives may help you out. Of course they have to be placed inside the nginx.conf file.
add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "default-src 'self'; font-src *;img-src * data:; script-src *; style-src *;";
add_header Referrer-Policy 'strict-origin';
To fine tune and understand these headers and cookies thing on both Apache HTTP and NGINX you can read this link from the Mozilla guys. Useful and instructive.
9.- Other resources
Yes, there are still many servers out there supporting old and depecrated versions of either SSL and TLS. And yet it’s not that much difficult to improve them. Of course things get complicated with scale and in big corporations being agile is just a funny joke too often.
I just hope this how to configure TLS 1.2 on UNIX or GNU/Linux helps some people or at least inspires them to improve their servers or devices.
This same setup can be built in DigitalOcean. Use this link to get 100 $ credit at DigitalOcean and support Adminbyaccident.com hosting costs.