TLSSLed v1.2 – Evaluate The Security Of A Target SSL Or TLS (HTTPS) Web Server Implementation

Keep on Guard!

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 the author strongly recommends taking 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.

There have been several tools to test for SSL and TLS security misconfiguration 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. One such tool is:

SSLyze v0.4 Released – Scan & Analyze SSL Server Configuration

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.

New in version 1.2: Mac OS X support, an initial check to verify if the target service speaks SSL/TLS, a few optimizations, and new tests for TLS v1.1 & v1.2 (CVE-2011-3389 aka BEAST).

New in version 1.1: Certificate public key length, the certificate subject and issuer (CA), as well as the validity period. It also checks the existence of HTTP secure headers, such as Strict-Transport-Security and cookies with and without the “secure” flag set.

You can download TLSSLed v1.2 here:

Or read more here.

Posted in: Cryptography, Web Hacking

, , , , , , , , ,

Recent in Cryptography:
- sslscan – Detect SSL Versions & Cipher Suites (Including TLS)
- UK Encryption Backdoor Law Passed Via Investigatory Powers Act
- Signal Messaging App Formal Audit Results Are Good

Related Posts:

Most Read in Cryptography:
- The World’s Fastest MD5 Cracker – BarsWF - 47,956 views
- Hackers Crack London Tube Oyster Card - 45,550 views
- WPA2 Vulnerability Discovered – “Hole 196” – A Flaw In GTK (Group Temporal Key) - 33,449 views

2 Responses to TLSSLed v1.2 – Evaluate The Security Of A Target SSL Or TLS (HTTPS) Web Server Implementation

  1. William December 16, 2012 at 9:18 am #


    It has been a long time since I have visited this site (busy with pentests, family, etc), but I thought I should provide some guidance about this tool that some may or may not be aware of.

    This post claims that this tool checks web sites for SSL version two support, however, on some modern Linux distributions, this simply just isn’t the case. Don’t get me wrong, this is a wonderfully scripted tool, but there are some issues this script appears not to take into account.

    As you can see in the source listed below (with line numbers), this tool works to assess the site using calls to openssl s_client and sslscan and logs to a temp log file. It then takes the output of those connections and uses e/grep (rant warning – grep sucks and less is more) to parse the file for security related issues:

    109 # Run sslcan once, store the results to a log file and
    110 # analyze that file for all the different tests:
    111 DATE=$(date +%F_%R:%S | sed ‘s/://g’)
    113 LOGFILE=sslscan\_$TARGET\_$DATE.log
    114 ERRFILE=sslscan\_$TARGET\_$DATE.err
    115 RENEGLOGFILE=openssl\_RENEG\_$TARGET\_$DATE.log
    116 RENEGERRFILE=openssl\_RENEG\_$TARGET\_$DATE.err
    117 HEADLOGFILE=openssl\_HEAD\_$TARGET\_$DATE.log
    118 HEADERRFILE=openssl\_HEAD\_$TARGET\_$DATE.err
    120 # Check if the target service speaks SSL/TLS (& check renegotiation)
    121 (echo R; sleep 5) | openssl s_client -connect $HOST:$PORT > $RENEGLOGFILE 2> $RENEGERRFILE &
    122 pid=$!
    123 sleep 5
    127 if [ $SSL_HANDSHAKE_LINES -lt 5 ] ; then
    128 # SSL handshake failed – Non SSL/TLS service
    129 # If the target service does not speak SSL/TLS, openssl does not
    130 # terminate
    131 kill -s SIGINT ${pid}
    133 echo “[+] ERROR: The target service $HOST:$PORT does not seem”
    134 echo ” to speak SSL/TLS or is not available!!”
    135 echo
    136 exit
    137 else
    138 # SSL handshake succeded – Continue
    139 echo “[*] The target service $HOST:$PORT seems to speak SSL/TLS…”
    140 echo
    141 fi
    144 echo
    145 echo [-] Running sslscan on $HOST:$PORT…
    146 sslscan $HOST:$PORT > $LOGFILE 2> $ERRFILE
    148 echo
    149 echo [*] Testing for SSLv2 …
    150 grep “Accepted SSLv2” $LOGFILE
    151 echo
    152 echo [*] Testing for NULL cipher …
    153 grep “NULL” $LOGFILE | grep Accepted
    154 echo
    155 echo [*] Testing for weak ciphers \(based on key length\) …

    What some users may or may not be aware about is their favorite Linux distribution may have simply chosen to remove SSL version two support without end user awareness. For example in Ubuntu, SSL version two support was removed back in mid to late 2010 around openssl version 0.98:

    This was largely done to protect the end user and ignorant system administrators, but there were other unforeseen impacts to this issue. While their intent was correct, there were unforeseen impacts to this decision, some of which actually impact this shell script.

    For example, just after the openssl 0.98 update with libraries that removed OpenSSL support in Ubuntu, users started noticing issues with their software. Again, using one of the tools that this shell script calls was impacted by this as suddenly users started getting the following error when attempting to make an SSL version two connection:

    “ERROR: Could not create CTX object.”

    Someone finally reported this issue:

    The disturbing fact is that to resolve this issue, some developers simply just silently removed the error that would alert users to an issue, as apposed to warning the user that their system no longer supports SSL version two:

    williams@helix:~$ sslscan –ssl2 localhost:443
    ___ ___| |___ ___ __ _ _ __
    / __/ __| / __|/ __/ _` | ‘_ \
    \__ \__ \ \__ \ (_| (_| | | | |
    |___/___/_|___/\___\__,_|_| |_|

    Version 1.8.2
    Copyright Ian Ventura-Whiting 2009

    Testing SSL server localhost on port 443

    Supported Server Cipher(s):

    Prefered Server Cipher(s):

    SSL Certificate:
    Version: 2

    Other package maintainers did not work to identify that they were going to be impacted by this move, or worked to correct the application. An example, which is better than the current state of sslscan, is openssl s_client, as shown here on a Ubuntu system:

    williams@helix:~$ openssl s_client -connect localhost:443 -ssl2
    unknown option -ssl2
    usage: s_client args

    -host host – use -connect instead
    -port port – use -connect instead
    -connect host:port – who to connect to (default is localhost:4433)
    -verify arg – turn on peer certificate verification

    -ssl2 – just use SSLv2
    -ssl3 – just use SSLv3
    -tls1_2 – just use TLSv1.2
    -tls1_1 – just use TLSv1.1
    -tls1 – just use TLSv1
    -dtls1 – just use DTLSv1

    Again, at least the user in this case is warned about an issue (if I wasn’t so busy pentesting, I would probably get to working to reporting this minor bug). For example, on the same system, after inspecting the source code (you do review the code you download from untrusted sources, don’t you?!?!), you can see that this script simply assumes client side SSL version support:

    williams@helix:~$ less -i ./Downloads/
    williams@helix:~$ sh ./Downloads/ localhost 443
    ./Downloads/ 78: [: Linux: unexpected operator
    TLSSLed – (1.2) based on sslscan and openssl
    by Raul Siles (
    + openssl version: OpenSSL 1.0.1 14 Mar 2012
    + sslscan version 1.8.2

    [-] Analyzing SSL/TLS on localhost:443 ..

    [*] The target service localhost:443 seems to speak SSL/TLS…

    [-] Running sslscan on localhost:443…

    [*] Testing for SSLv2 …

    [*] Testing for NULL cipher …

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

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

    [*] Testing for MD5 signed certificate …

    [*] Testing for certificate public key length …


    In summary, if an inexperienced auditor is working to utilize this tool to assess websites using HTTPS protections and that auditor is unaware of the fact that their platform’s chosen implementation of client side SSL support is not built with SSL version two support, such an auditor may be overlooking or missing a security related issue with a protocol or service (more than likely HTTPS in this case) that does in fact support SSL version 2 connections. This is especially true as in my experience, even modern vendor solutions come with this enabled by default (for some reason). I see this over and over and over.

    That being said, I have some things to keep in mind about SSL/TLS layered protections (outside of the fact that your platform may be lying to you).

    Given that SSL/TLS is application neutral protocol, any higher layer application protocol (such as SMTP, TELENT, FTP, HTTP, etc) can be built on top of SSL/TLS in a transparent fashion, creating a secure tunnel during the session. An example of this would be FTPS, which is the FTP clear-text protocol adding support for transport protection using TLS/SSL

    The same thing happens with HTTPS, where HTTPS really isn’t a protocol
    in and of itself (dare I say at the risk of an RFC flame war), but the HTTP protocol with support for layering the HTTP protocol on top of the SSL/TLS protocol for transport protection and host identification and verification.

    The SMTP protocol does this using the ‘STARTTLS’ command by initiating a
    clear-text session using the transport and application layers, then
    working to protect the session information using SSL/TLS:

    It should also be noted that TLS is backwards compatible with SSL version two as discussed in RFC 5246:

    I share this with all of you because the article mentions a potential targeted user base that might feel the need to use such a tool (TLSSLed), due to a feeling of lack of experience or knowledge leading one to believe they may not know how to look for or identify security related issues with protocols/services using SSL/TLS layer protections. If this is the case, please take some advice from a Senior Technical Auditor, as any respected ISO 27001 team leader will attest to, if you do not have the experience or training to assess such protocols, you need to find someone else to conduct the assessment, or you need to get yourself trained!

    That being said, if you are in a position where neither of these are possible at the moment and you must assess some service, it is important to look for SSL/TLS support in other protocols outside of the HTTPS protocol, at all hops from the client to the server, as any service/application can be built to utilize such protections. This is important, as many choose to disregard such support on other protocols outside of HTTPS/HTTPS-ALT. If any service/protocol is using a vulnerable insecure instance of SSL/TLS to protect an application and client/server connection, the very application/service that the SSL/TLS instance is intended to protect may be at risk. In summary, do not assume that there is only risk tied to a website with SSL/TLS support. Look for issues at all sorts of applications (SMTP servers, FTP server, proxy ‘firewalls’ – LOL, etc).

    Anyways, that is all that I have for you all.

    Happy Hacking ;)


    • Darknet December 24, 2012 at 1:51 pm #

      Excellent insights there William and definitely a factor that many will overlook, especially with the newer operating systems excluding it by default.