Friday, May 27, 2011

TLSSLed v1.0

When running web application security assessments it is mandatory to evaluate the security stance of the SSL/TLS (HTTPS) implementation and configuration. OWASP has a couple of references I strongly recommend to take a look at, the "OWASP-CM-001: Testing for SSL-TLS" checks, part of the OWASP Testing Guide v3, and the Transport Layer Protection Cheat Sheet.

We have had several tools to test for SSL and TLS security misconfigurations along the years, but still today, lots of people get the output from all these tools and are not very sure what they need to look at. Apart from the SSL/TLS web application best practices, it is important to also check the security of SSL/TLS at the web platform layer.

The purpose of the TLSSLed tool (named from the idea of your website being TLS/SSL-ed, that is, using "https;//") is to simplify the output of a couple of commonly used tools, and highlight the most relevant security findings of any target SSL/TLS implementation. It is based on sslscan, a thorough SSL/TLS scanner that is based on the openssl library, and on the "openssl s_client" command line tool.

TLSSLed is a Linux shell script inspired on by Aung Khant, where a few optimizations have been made to reduce the stress on the target web server (sslscan is run only once and the results are stored on a local file), and some tests have been added and tuned.

The current tests include checking if the target supports the SSLv2 protocol, the NULL cipher, weak ciphers based on their key length (40 or 56 bits), the availability of strong ciphers (like AES), if the digital certificate is MD5 signed, and the current SSL/TLS renegotiation capabilities. The tool is open to comments, suggestions, improvements and new tests from the community. Do not hesitate to contact me with ideas!

NOTE: First idea for v1.1 - Would it be useful to check for the certificate key length (<= 1024 bits)?

TLSSLed v1.0 can be downloaded from Taddong's lab.

The following output shows how to use TLSSLed and the kind of results you will get. It only requires two arguments ("yes, I know, with no verification..."): the target HTTPS server hostname (or IP address) and the target port. The example below shows a secure implementation from, because unfortunately, I'm sure you will find multiple insecure examples out there (Make your web environment look the same!):

$ ./ 443
 TLSSLed - (1.0) based on sslscan and openssl
 by Raul Siles (
 ( inspired by by Aung Khant )
+ openssl version: OpenSSL 0.9.8g 19 Oct 2007
+ sslscan version 1.8.2

[*] Analyzing SSL/TLS on ..

[*] Running sslscan on

[*] Testing for SSLv2 ...

[*] Testing for NULL cipher ...

[*] Testing for weak ciphers (based on key length) ...

[*] Testing for strong ciphers (AES) ...
    Accepted  SSLv3  256 bits  DHE-RSA-AES256-SHA
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
    Accepted  TLSv1  128 bits  AES128-SHA

[*] Testing for MD5 signed certificate ...

[*] Checking preferred server ciphers ...
  Prefered Server Cipher(s):
    SSLv3  256 bits  DHE-RSA-AES256-SHA
    TLSv1  256 bits  DHE-RSA-AES256-SHA

[*] Testing for SSLv3/TLSv1 renegotiation vuln. (CVE-2009-3555) ...
depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy ...
... Validation Authority/CN=
verify error:num=19:self signed certificate in certificate chain
verify return:0
Secure Renegotiation IS supported
12172:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

[*] New files created:
-rw-r--r-- 1 samurai samurai 5980 2011-05-27 19:47

[*] done


Erik Karulf said...

It might be worth checking to see if the host's ssl key is weak by against openssl-blacklist(8).

Raul Siles said...

Erik, thanks for the suggestion. I will consider it for the next version (v1.2+). My main concern is that openssl-blacklist might not be available in lots of systems, so this will increase the tool prerequisites (it could be an optional feature).

Anonymous said...

After Ekopary, there's an obvious test to check for...tls 1.1/1.2 enabled.

Raul Siles said...

No doubt about it :) It is on the TODO list for version 1.2. The main issue is that you need the latest openssl versions to check for it.

Post a Comment