If you are in charge of any site with SSL/TLS conenctions enabled you are always in the chase to get the best possible and most secure configuration. This isn’t always the case and the lack of time does take its toll on many administrators. Those individuals are always asked to do more with less and sometimes what they are asked to do is simply ridiculous. Automation can help but first one needs to find the right tools.
To test SSL/TLS configurations there are a few tools in the market. There are also sites that will examine your configuration for free. One of these sites is hosted at SSLLabs.com, a site property of Qualys, a cyber security company.
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.
By placing your domain name you get a free examination for your SSL/TLS configuration.
You should always aim to the highest result possible.
If you need to do this en mass, Qualys does also have a program to access their API and for a fee you can test as many sites as you need. However, that is a paid service.
There’s an alternative you may want to use before using any third party verification software. Enter testssl.sh.
This wonderful program helps anyone to test SSL/TLS configurations at no cost, straight from the command line and with a clear view of what is OK, what is a warning and what bits of the configuration are wrong. It is available on every GNU/Linux distro and on the BSDs as well. You can also get its latest iteration from the project’s github repostory. Donations to the project are welcome, so you can help them out on improving the tools for our security.
This is an example of how to install testssl.sh on FreeBSD.
albert@BSDVM:~ % uname -a
FreeBSD BSDVM 12.2-RELEASE-p4 FreeBSD 12.2-RELEASE-p4 GENERIC amd64
albert@BSDVM:~ % pkg search testssl.sh
testssl.sh-3.0.4 Analyze and report TLS/SSL configuration/misconfiguration
albert@BSDVM:~ % sudo pkg install -y testssl.sh
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 3 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
bash: 5.1.4_1
openssl-unsafe: 1.0.2.20170706
testssl.sh: 3.0.4
Number of packages to be installed: 3
The process will require 23 MiB more space.
4 MiB to be downloaded.
[1/3] Fetching testssl.sh-3.0.4.txz: 100% 677 KiB 693.1kB/s 00:01
[2/3] Fetching bash-5.1.4_1.txz: 100% 1 MiB 1.5MB/s 00:01
[3/3] Fetching openssl-unsafe-1.0.2.20170706.txz: 100% 2 MiB 2.1MB/s 00:01
Checking integrity... done (0 conflicting)
[1/3] Installing bash-5.1.4_1...
[1/3] Extracting bash-5.1.4_1: 100%
[2/3] Installing openssl-unsafe-1.0.2.20170706...
[2/3] Extracting openssl-unsafe-1.0.2.20170706: 100%
[3/3] Installing testssl.sh-3.0.4...
[3/3] Extracting testssl.sh-3.0.4: 100%
=====
Message from openssl-unsafe-1.0.2.20170706:
--
/!\ ================================ /!\ ============================== /!\
/!\ /!\
/!\ This openssl version is for security testing/scanning purposes only /!\
/!\ /!\
/!\ DO NOT USE FOR PRODUCTION PURPOSES /!\
/!\ /!\
/!\ ================================ /!\ ============================== /!\
albert@BSDVM:~ %
Once installed let’s test SSL/TLS configurations from some site.
To use testssl.sh one just needs to invoke it and point to a domain or IP and wait for results. Since the output is a bit long I’ll leave the full result view for the tinkerer among the Adminbyaccident.com readers. However, I’d like to comment on a few places.
This next site is not very well configured so it’s got a few places where testssl.sh will complain. Furthermore, the certificate in use is self signed which will be also pointed out by the tool.
An interesting bit is where testssl.sh looks for vulnerabilities.
This particular box is vulnerable to the SWEET attack. And the tool has found it.
But there are other interesting bits, such as how headers have been configured. This is an important bit so connection downgrade attacks (from HTTPS to HTTP) can’t be performed, or cross-site ones are also blocked.
No security headers is a bad sign. To test SSL/TLS configurations and find no results on the ‘Strict Transport Security’’ find a full ‘Server banner’ and no ‘Security headers’ gives a very bad impression.
The testssl.sh tool does also look for other misconfigurations such as offering older versions of the SSL/TLS protocols like SSLv2, SSLv3 or the already deprecated too, TLSv1.0 and TLSv1.1. Mind the only current ones are TLSv1.2 and TLSv1.3 at the time of writing this piece.
To find this old protocol versions being offered is also important. Many corporations are still offering old versions of the protocols. They why is unimportant. They need to fix this ASAP.
Another important bit is if the SSL/TLS configuration is supported on the clients that will use the server.
Testssl.sh does more things, like checking perfect forward secrecy, checks the supported cipher suites, checks the certificate in and out and a few more bits.
A very nice tool to test SSL/TLS configurations everywhere. With a bit of time and a small script this can be used to automate findings in large environments. Some may be surprised of the results.
If you are one of those do not hesitate to help the project and donate some needed money, or even some of your skills!
To conclude if you need some help on how to configure some of the security bits on your Apache HTTP you can read a couple of guides I’ve written on this topic.
https://www.adminbyaccident.com/security/how-to-harden-apache-http/
If you find the articles in Adminbyaccident.com useful to you, please consider making a donation.
Use this link to get $200 credit at DigitalOcean and support Adminbyaccident.com costs.
Get $100 credit for free at Vultr using this link and support Adminbyaccident.com costs.
Mind Vultr supports FreeBSD on their VPS offer.