Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy

There are situations when we need to increase the encryption level on the old system – according to the PCI audit requirements. However, the old system is no longer supported, so updating the encryption level is not possible. This is not a recommended solution, because we should try to transfer the application to a new system. After all, when we have little time, it is possible to hide the old version of the system and allow only the new machine to move to it. In this particular example, we will use mod_proxy as a proxy to redirect traffic to the old machine, while using iptables we will only allow communication with the new machine. It is not a recommended solution, but it works and I would like to present it here. The systems that I will be basing on in this example are the old red hat 5 and the new oracle linux 7. Recently, it has become very important to use a minimum of tls 1.2 and none below for banking transactions. Let’s start with the proxy server configuration oracle linux 7.

As of this writing, the addressing is as follows:
new_machine IP:
old_machine IP:
Traffic will be routed on port 443 from new_machine to old_machine.

Before we go to proxy configuration, please make sure there are network transitions from new_machine ( to old_machine ( to port 443. You can read how to verify network connections here: check network connection and open tcp port via netcat.

We go to the installation of apache and mod_proxy:

After installing apache, go to the edition:

Below are the news on the check level, what are the updates, and ip on the next service update:

In order to verify the correctness of apache configuration, you can issue a command that will check it:

If the apache configuration is correct, we can proceed to reloading apache:

At this point, we have a configured proxy connection. Before we move on to limiting traffic with iptables, I suggest you go to the site – with the new mod_proxy configured and test if everything is working properly and if there are any problems with the application.

Once everything is working fine, the network transitions are there, we can go to the iptables configuration for red hat 5. Let’s start by checking the system version:

Now we are going to prepare iptables so that the network traffic is available on port 443 from the new_machine ( To do this, edit the file /etc/sysconfig/iptables:

After iptables settings are correct, we can reload the service:

In this way, we managed to cover up the weak encryption by proxying and diverting traffic to the new machine. This is not a recommended solution and you should try to transfer the application to a new environment compatible with the new system. However, in crisis situations, we can use this solution. Network traffic is not allowed by other IP addresses, so scanners will not be able to detect weak encryption on the old machine, and users using the old environment will not be able to use it. This does not change the fact that weak encryption is still set in the old environment and needs to be corrected. The example I gave is for the old red hat 5 and the new oracle linux 7, but it can be assumed that a similar solution and configuration is possible for other versions of the system.

Checking SSL certyfikat date using nmap and curl

This time I will use Kali Linux it is a great distro for pentesters. After all, nothing prevents you from using another distribution, such as Debian Linux.

Sometimes we need to check the certificate issuance date. Nmap and curl are a very good tool for this.
Both of these tools allow for advanced analysis of the SSL connection. Let’s try to check the certificate date with nmap:

To be more precise, let’s leave the date and time alone:

Here is the result:

In my experience nmap is a very good tool – however curl is much faster, to use it, do the following:

This is the effect:

It is worth getting acquainted with both tools. Besides checking the date of the certificate, they offer a number of other possibilities.

nmap scaning ciphers and ssl

In debian 11:

Nmap is one of more powerfull tools to scaning network.
We start the installation on debian as root:

and than we can check for example

It’s much slower than sslscan, but result is the same (tls 1.1, 1.2 and tls 1.3).

TLS 1.0:

TLS 1.1:

TLS 1.2:

The most important thing is don’t using vulnerable ciphers, and reading output of nmap, for example in this case:
“64-bit block cipher 3DES vulnerable to SWEET32 attack” – on SWEET32 vulnerability.
When we testing external website available from internet you can use but if we have internal server nmap in this case is very good solution to use.

sslscan tool for scaning SSL

In debian 11:

One of the best tool for scaning ssl is sslscan in Linux.
You can install on debian like this as root of course:

and than we can check for example

As you see, google use now tls 1.0, 1.1, 1.2 and 1.3: