Archiwa SSL - soban https://soban.pl/category/ssl/ IT, Linux, Servers, Security Thu, 26 Feb 2026 14:13:08 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.1 Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy https://soban.pl/improving-encryption-on-old-red-hat-5-by-new-oracle-linux-7-using-apache-mod_proxy/ Sat, 06 Nov 2021 13:54:17 +0000 https://soban.pl/?p=308 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 […]

Artykuł Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy pochodzi z serwisu soban.

]]> 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: 10.10.14.100
old_machine IP: 10.10.14.101
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 (10.10.14.100) to old_machine (10.10.14.101) 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:

# yum install httpd mod_proxy

After installing apache, go to the edition:

# vi /etc/httpd/conf.d/ssl.conf

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

<VirtualHost _default_:443>
SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!DES:!3DES:!SHA:!SHA256:!SHA384:!MD5+HIGH:+MEDIUM:!KRB5
#…
<IfModule mod_proxy.c>
SSLProxyProtocol all
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyRequests On
    <Proxy *>
        Require all granted
    </Proxy>
    # backend server and forwarded path
    ProxyPass / https://10.10.14.101/
    ProxyPassReverse / https://10.10.14.101/
</IfModule>
</VirtualHost>

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

# service httpd configtest

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

# service httpd restart

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:

# cat /etc/redhat-release

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

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 443 -s 10.10.14.100 -j ACCEPT
-A INPUT -p tcp --dport 443 -j DROP
-A INPUT -p tcp --dport 80 -j DROP
-A INPUT -j ACCEPT
COMMIT

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

# /etc/init.d/iptables restart

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.

Artykuł Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy pochodzi z serwisu soban.

]]> Checking SSL certyfikat date using nmap and curl https://soban.pl/checking-ssl-certyfikat-date-using-nmap-and-curl/ Thu, 14 Oct 2021 18:04:14 +0000 https://soban.pl/?p=123 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 […]

Artykuł Checking SSL certyfikat date using nmap and curl pochodzi z serwisu soban.

]]> 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:

$ nmap -p 443 --script ssl-cert soban.pl

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

$ nmap -p 443 --script ssl-cert soban.pl | grep after | awk '{ print $5 }'

Here is the result:

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

$ curl -X GET -i 'https://google.com' | grep -i 'date:' | grep GMT

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.

Artykuł Checking SSL certyfikat date using nmap and curl pochodzi z serwisu soban.

]]> nmap scaning ciphers and ssl https://soban.pl/nmap-scaning-ciphers-and-ssl/ Thu, 30 Sep 2021 21:11:59 +0000 https://soban.pl/?p=35 Nmap – scanning SSL/TLS ciphers on Debian 11 In this example we are working on Debian 11 (Bullseye). First, let’s confirm the system version: Nmap is one of the most powerful network scanning tools available on Linux. It allows you to scan open ports, detect running services, identify software versions and analyze supported SSL/TLS protocols […]

Artykuł nmap scaning ciphers and ssl pochodzi z serwisu soban.

]]> Nmap – scanning SSL/TLS ciphers on Debian 11

In this example we are working on Debian 11 (Bullseye). First, let’s confirm the system version:

# cat /etc/issue
Debian GNU/Linux 11 \n \l

Nmap is one of the most powerful network scanning tools available on Linux. It allows you to scan open ports, detect running services, identify software versions and analyze supported SSL/TLS protocols and cipher suites.

Installation on Debian 11 is simple:

# apt install nmap

After installation, we can test a remote HTTPS server. For example:

# nmap -sV --script ssl-enum-ciphers -p 443 google.com

The -sV option enables service version detection and --script ssl-enum-ciphers checks supported TLS versions and encryption ciphers. This allows you to verify which TLS versions are enabled (TLS 1.0, 1.1, 1.2, 1.3), whether weak ciphers like 3DES are supported and if potential cryptographic vulnerabilities exist.

Nmap is slower than tools like sslscan, but the level of detail is very good and useful especially for internal infrastructure testing.

TLS 1.0:

TLS 1.0 scan result using Nmap

TLS 1.1:

TLS 1.1 scan result using Nmap

TLS 1.2:

TLS 1.2 cipher suites detected by Nmap

The most important thing when analyzing SSL/TLS configuration is checking for weak or vulnerable ciphers. For example, if you see: “64-bit block cipher 3DES vulnerable to SWEET32 attack”, it means the server still supports 3DES, which is vulnerable to the SWEET32 attack. In production environments such ciphers should be disabled.

If you are testing a public website, you can also use https://www.ssllabs.com/ssltest/. However, for internal servers, staging environments or private infrastructure, using Nmap directly from your Debian system is often the best solution. Regular SSL/TLS scanning helps keep your infrastructure secure and ensures that outdated protocols and weak encryption methods are eliminated.

Artykuł nmap scaning ciphers and ssl pochodzi z serwisu soban.

]]> sslscan tool for scaning SSL https://soban.pl/sslscan-tool-for-scaning-ssl/ Wed, 29 Sep 2021 21:11:43 +0000 https://soban.pl/?p=31 SSLScan is a command-line tool used for SSL/TLS vulnerability scanning. It is used to detect SSL/TLS vulnerabilities and weaknesses on servers that use SSL/TLS. SSLScan supports all SSL and TLS protocols and cipher suites, including new ones such as TLS 1.3. SSLScan can be used to identify various SSL/TLS vulnerabilities, such as weak ciphers and […]

Artykuł sslscan tool for scaning SSL pochodzi z serwisu soban.

]]> SSLScan is a command-line tool used for SSL/TLS vulnerability scanning. It is used to detect SSL/TLS vulnerabilities and weaknesses on servers that use SSL/TLS. SSLScan supports all SSL and TLS protocols and cipher suites, including new ones such as TLS 1.3.

SSLScan can be used to identify various SSL/TLS vulnerabilities, such as weak ciphers and encryption algorithms, insecure renegotiation, and Heartbleed attacks. It can also identify unsupported SSL/TLS versions and protocols, as well as expired or self-signed certificates.

SSLScan works by connecting to the target server and sending a series of SSL/TLS handshake messages to determine the supported protocols and cipher suites. It then checks for vulnerabilities and weaknesses by trying various attacks against the server, such as malformed SSL/TLS packets and invalid certificates.

SSLScan can be run from the command line and supports various options and flags to customize the scan. For example, it can be used to scan a specific port, specify the SSL/TLS version, or use a specific cipher suite.

Overall, SSLScan is a useful tool for checking SSL/TLS vulnerabilities and ensuring that servers are secure. It is commonly used by security professionals and system administrators to identify and mitigate SSL/TLS vulnerabilities on their networks.

In debian 11:

# cat /etc/issue
Debian GNU/Linux 11 \n \l

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

# apt install sslscan
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  sslscan
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 53.4 kB of archives.
After this operation, 182 kB of additional disk space will be used.
Get:1 http://ftp.debian.org/debian bullseye/main amd64 sslscan amd64 2.0.7-1 [53.4 kB]
Fetched 53.4 kB in 0s (509 kB/s)
Selecting previously unselected package sslscan.
(Reading database ... 65077 files and directories currently installed.)
Preparing to unpack .../sslscan_2.0.7-1_amd64.deb ...
Unpacking sslscan (2.0.7-1) ...
Setting up sslscan (2.0.7-1) ...
Processing triggers for man-db (2.9.4-2) ...

and than we can check for example google.com:

$ sslscan google.com:443
Version: 2.0.7
OpenSSL 1.1.1k  25 Mar 2021

Connected to 142.250.179.78

Testing SSL server google.com on port 443 using SNI name google.com

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384
Accepted  TLSv1.2  128 bits  AES128-SHA
Accepted  TLSv1.2  256 bits  AES256-SHA
Accepted  TLSv1.2  112 bits  TLS_RSA_WITH_3DES_EDE_CBC_SHA
Preferred TLSv1.1  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
Accepted  TLSv1.1  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
Accepted  TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
Accepted  TLSv1.1  128 bits  AES128-SHA
Accepted  TLSv1.1  256 bits  AES256-SHA
Accepted  TLSv1.1  112 bits  TLS_RSA_WITH_3DES_EDE_CBC_SHA
Preferred TLSv1.0  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
Accepted  TLSv1.0  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
Accepted  TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
Accepted  TLSv1.0  128 bits  AES128-SHA
Accepted  TLSv1.0  256 bits  AES256-SHA
Accepted  TLSv1.0  112 bits  TLS_RSA_WITH_3DES_EDE_CBC_SHA

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  128 bits  x25519
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  128 bits  x25519

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      prime256v1
ECC Key Strength:    128

Subject:  *.google.com
Altnames: DNS:*.google.com, DNS:*.appengine.google.com, DNS:*.bdn.dev, DNS:*.cloud.google.com, DNS:*.crowdsource.google.com, DNS:*.datacompute.google.com, DN
S:*.google.ca, DNS:*.google.cl, DNS:*.google.co.in, DNS:*.google.co.jp, DNS:*.google.co.uk, DNS:*.google.com.ar, DNS:*.google.com.au, DNS:*.google.com.br, DN
S:*.google.com.co, DNS:*.google.com.mx, DNS:*.google.com.tr, DNS:*.google.com.vn, DNS:*.google.de, DNS:*.google.es, DNS:*.google.fr, DNS:*.google.hu, DNS:*.g
oogle.it, DNS:*.google.nl, DNS:*.google.pl, DNS:*.google.pt, DNS:*.googleadapis.com, DNS:*.googleapis.cn, DNS:*.googlevideo.com, DNS:*.gstatic.cn, DNS:*.gsta
tic-cn.com, DNS:*.gstaticcnapps.cn, DNS:googlecnapps.cn, DNS:*.googlecnapps.cn, DNS:googleapps-cn.com, DNS:*.googleapps-cn.com, DNS:gkecnapps.cn, DNS:*.gkecn
apps.cn, DNS:googledownloads.cn, DNS:*.googledownloads.cn, DNS:recaptcha.net.cn, DNS:*.recaptcha.net.cn, DNS:widevine.cn, DNS:*.widevine.cn, DNS:ampproject.o
rg.cn, DNS:*.ampproject.org.cn, DNS:ampproject.net.cn, DNS:*.ampproject.net.cn, DNS:google-analytics-cn.com, DNS:*.google-analytics-cn.com, DNS:googleadservi
ces-cn.com, DNS:*.googleadservices-cn.com, DNS:googlevads-cn.com, DNS:*.googlevads-cn.com, DNS:googleapis-cn.com, DNS:*.googleapis-cn.com, DNS:googleoptimize
-cn.com, DNS:*.googleoptimize-cn.com, DNS:doubleclick-cn.net, DNS:*.doubleclick-cn.net, DNS:*.fls.doubleclick-cn.net, DNS:*.g.doubleclick-cn.net, DNS:doublec
lick.cn, DNS:*.doubleclick.cn, DNS:*.fls.doubleclick.cn, DNS:*.g.doubleclick.cn, DNS:dartsearch-cn.net, DNS:*.dartsearch-cn.net, DNS:googletraveladservices-c
n.com, DNS:*.googletraveladservices-cn.com, DNS:googletagservices-cn.com, DNS:*.googletagservices-cn.com, DNS:googletagmanager-cn.com, DNS:*.googletagmanager
-cn.com, DNS:googlesyndication-cn.com, DNS:*.googlesyndication-cn.com, DNS:*.safeframe.googlesyndication-cn.com, DNS:app-measurement-cn.com, DNS:*.app-measur
ement-cn.com, DNS:gvt1-cn.com, DNS:*.gvt1-cn.com, DNS:gvt2-cn.com, DNS:*.gvt2-cn.com, DNS:2mdn-cn.net, DNS:*.2mdn-cn.net, DNS:googleflights-cn.net, DNS:*.goo
gleflights-cn.net, DNS:admob-cn.com, DNS:*.admob-cn.com, DNS:*.gstatic.com, DNS:*.metric.gstatic.com, DNS:*.gvt1.com, DNS:*.gcpcdn.gvt1.com, DNS:*.gvt2.com,
DNS:*.gcp.gvt2.com, DNS:*.url.google.com, DNS:*.youtube-nocookie.com, DNS:*.ytimg.com, DNS:android.com, DNS:*.android.com, DNS:*.flash.android.com, DNS:g.cn,
 DNS:*.g.cn, DNS:g.co, DNS:*.g.co, DNS:goo.gl, DNS:www.goo.gl, DNS:google-analytics.com, DNS:*.google-analytics.com, DNS:google.com, DNS:googlecommerce.com,
DNS:*.googlecommerce.com, DNS:ggpht.cn, DNS:*.ggpht.cn, DNS:urchin.com, DNS:*.urchin.com, DNS:youtu.be, DNS:youtube.com, DNS:*.youtube.com, DNS:youtubeeducat
ion.com, DNS:*.youtubeeducation.com, DNS:youtubekids.com, DNS:*.youtubekids.com, DNS:yt.be, DNS:*.yt.be, DNS:android.clients.google.com, DNS:developer.androi
d.google.cn, DNS:developers.android.google.cn, DNS:source.android.google.cn
Issuer:   GTS CA 1C3

Not valid before: Aug 30 01:36:08 2021 GMT
Not valid after:  Nov 22 01:36:07 2021 GMT

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

Artykuł sslscan tool for scaning SSL pochodzi z serwisu soban.

]]>