Tool Tuesday – TLS/SSL Scanning Tools
There are countless tools and variants for testing TLS/SSL connections. With these three simple tools you can easily check your own configuration.
In a nutshell: TLS (Transport Layer Security) and its previous version SSL (Secure Socket Layer) are protocols that are used for encrypted data transmission. Various parameters are negotiated between the client and server during connection setup. Which parameters are available for negotiation is defined in the server configuration.
In order to check this configuration – whether for a penetration test or for the in-house compliance check – various tools are available to facilitate the work.
We picked three tools: O-Saft, sslscan and testssl and compared them with each other.
O-Saft first captivates with its original name. It is a Perl based scanner with a lot of options. The special feature is that O-Saft not only evaluates and outputs the offered ciphers of the server but the scanner can also open a TCP socket and send SSL/TLS handshakes. The big advantage of this method is that the presence of SSLv2 can be tested without additional or outdated libraries.
The output is in text form on the console. This can optionally be redirected to a file.
More information can be found at: https://github.com/OWASP/O-Saft
sslcan must be installed or compiled. Self compiling has the advantage that you can use old openssl libraries to test SSLv2 or SSLv3 for example. The output appears very clear and divided into different colors on the console (great for screenshots). Alternatively, the output can be in the form of an XML file.
More information can be found at: https://github.com/rbsec/sslscan
testssl is a bash script. Therefore no installation or compilation is necessary. The scanner uses the current openssl version on the system. So only protocols and ciphers supported by the current openssl can be tested. The output is very extensive. It does not only give information about the used ciphers and certificates but also about possible vulnerabilities and attacks. In addition, the output can be written in various formats, such as a JSON file or CSV file, for further processing.
More information under: https://github.com/drwetter/testssl.sh
Do you have any questions about TLS/SSL security? Please feel free to contact us!
The NinjaDVA is our comfortable and flexible training environment.
Is your web application vulnerable to SQL Injection? With sqlmap you can test it.
CSRF Countermeasures #1: One possibility to prevent CSRF is the usage of an anti-CSRF token.
CSRF stands for “Cross-Site Request Forgery” and is a classic among web application attacks. With this attack, it is possible to perform certain user actions without them noticing it. But how exactly does this attack work?
At the it-sa 2019 we will present our innovative consulting concept Lean Application Security.