How to use the command 'testssl' (with examples)
Testssl is a powerful command-line tool designed to test and analyze the configuration of SSL/TLS on a server. It provides detailed insights into the security protocols and ciphers supported by a server, identifies potential vulnerabilities, and verifies HTTP security headers. By using this tool, server administrators can ensure that their systems are compliant with security standards and protected against various attack vectors.
Use case 1: Test a server (run every check) on port 443
Code:
testssl example.com
Motivation: Running every check available using testssl on a standard port (443, for HTTPS traffic) provides a comprehensive security assessment. This full scan is crucial for understanding the security posture of any public-facing server and ensuring there are no weak points in the SSL/TLS configuration.
Explanation:
testssl: This is the command to execute the testssl script.example.com: This specifies the domain name of the server you wish to check. By omitting a port number after the domain, it defaults to port 443, which is the standard HTTPS port.
Example Output:
Start 2023-10-10 18:45:56
Testing example.com (61.9.234.16) using SNI name: example.com on port 443
...
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered (deprecated)
TLS 1.1 offered (deprecated)
TLS 1.2 offered (OK)
TLS 1.3 offered (OK)
...
Use case 2: Test a different port
Code:
testssl example.com:465
Motivation: Testing a server on a non-standard port is essential. Ports like 465 are often used for protocols like SMTP over SSL. It’s important to ensure that these alternative ports are also securely configured.
Explanation:
testssl: The command to initiate the testssl script.example.com:465: Indicates the server domain and the specific port number (465) to test, which is known for SMTP over SSL.
Example Output:
Start 2023-10-10 18:50:21
Testing example.com (61.9.234.16) using SNI name: example.com on port 465
...
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered (deprecated)
TLS 1.1 offered (deprecated)
...
Use case 3: Only check available protocols
Code:
testssl --protocols example.com
Motivation: Checking only the available protocols helps in verifying that the server is not supporting outdated or vulnerable protocols that can be exploited by attackers.
Explanation:
testssl: Begins the testssl script execution.--protocols: Limits the check to only list available SSL/TLS protocols supported by the server.example.com: The domain whose protocol support we are testing.
Example Output:
Test protocols for example.com (61.9.234.16):
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered (deprecated)
TLS 1.1 offered (deprecated)
TLS 1.2 offered (OK)
TLS 1.3 offered (OK)
Use case 4: Only check vulnerabilities
Code:
testssl --vulnerable example.com
Motivation: To ensure a server is fortified against known vulnerabilities, administrators might choose to scan specifically for weaknesses. This keeps the server resilient against known attacks such as Heartbleed, POODLE, and DROWN.
Explanation:
testssl: The command initiating the script.--vulnerable: Option that instructs testssl to specifically check for known vulnerabilities.example.com: Domain of the server being assessed for vulnerabilities.
Example Output:
Vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK)
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK)
ROBOT not vulnerable (OK)
...
Use case 5: Only check HTTP security headers
Code:
testssl --headers example.com
Motivation: HTTP security headers are vital for protecting web applications against various attacks, including XSS, clickjacking, and data injection. Ensuring these headers are properly configured is a best practice in web security.
Explanation:
testssl: To start running the testssl script.--headers: Option restricting the checks to HTTP security headers only.example.com: Represents the domain name of the server whose HTTP security headers you are verifying.
Example Output:
HTTP security headers:
Strict-Transport-Security max-age=63072000; includeSubdomains; preload
Content-Security-Policy default-src 'none'; script-src 'self'
X-Content-Type-Options nosniff
X-Frame-Options SAMEORIGIN
X-XSS-Protection 1; mode=block
Use case 6: Test other STARTTLS enabled protocols
Code:
testssl --starttls smtp example.com:587
Motivation: For servers that use STARTTLS to upgrade a plaintext connection to a secure one, it is critical to ensure these protocols are securely configured. This test helps verify such configurations, particularly important for email services.
Explanation:
testssl: Begins the execution of the testssl script.--starttls smtp: Specifies that the STARTTLS capability for the SMTP protocol should be checked.example.com:587: The domain and port checked, with 587 typically used for SMTP with STARTTLS.
Example Output:
StartTLS for smtp commenced
...
Testing protocols via STARTTLS on smtp
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered (deprecated)
TLS 1.1 offered (deprecated)
TCP support found (OK)
...
Conclusion:
Testssl provides a comprehensive suite of tests designed to evaluate the security configuration of SSL/TLS across various domains and ports. By understanding and utilizing these specific use cases, server administrators can diagnose and fortify their server setups, ensuring protection from vulnerabilities and compliance with best security practices. Whether testing a standard configuration or focusing on specific components such as protocols or vulnerabilities, testssl proves to be an indispensable tool in the realm of cybersecurity.
