TLSSLed v1.2

TLSSLed v1.2 has been released and can be downloaded, as usual, from Taddong's lab.

This new version incorporates feedback from several people, as well as new features, including support for Mac OS X (TLSSLed should now run in both Linux and Mac OS X; check how to build sslscan on Mac OS X first), an initial check to verify if the target service speaks SSL/TLS (finishing its execution if it does not), a few other optimizations and error checks, and new tests for TLS v1.1 and v1.2.

The latter feature has been added as a result of the recent BEAST vulnerability and research, CVE-2011-3389. In order to be able to check for TLS v1.1 and v1.2 you need to use openssl-1.0.1-stable, available from the openssl snapshot repository. TLSSLed identifies if the target service supports TLS v1.1 and v1.2, if it does not, or if your local openssl version does not support these TLS versions.

This new test simply checks if the target service supports these two TLS versions, however, this does not mean the implementation is secure from a BEAST perspective, as lots of other factors can influence this, such as:

• The implementation could downgrade from TLS v1.1 or v1.2 to TLS v1.0 or SSLv3 if these versions are also supported by the server and a client requests it.
• The implementation can use RC4 instead of AES CBC to mitigate this vulnerability.
• Certain SSL/TLS implementations might not be vulnerable to BEAST, such as openssl since version 0.9.6d, as they already added empty plaintext fragments (problem #2) - if SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not set.

The first two scenarios can be easily verified through the new "Testing for SSLv3 and TLSv1 support first ..." test. If you know how to remotely check for the third scenario using the openssl binary, I would love to hear about it and implement that inside the tool... Therefore, a careful and thorough brain-based analysis is still required :)

The output below shows this new feature against "tls.woodgrovebank.com", an SSL/TLS public Interop Test Server from Microsoft, using openssl 1.0.1-dev:

$ ./TLSSLed.sh tls.woodgrovebank.com 443 ------------------------------------------------------ TLSSLed - (1.2) based on sslscan and openssl by Raul Siles (www.taddong.com) ------------------------------------------------------ + openssl version: OpenSSL 1.0.1-dev xx XXX xxxx + sslscan version 1.8.2 ------------------------------------------------------ [-] Analyzing SSL/TLS on tls.woodgrovebank.com:443 .. [*] The target service tls.woodgrovebank.com:443 seems to speak SSL/TLS... [-] Running sslscan on tls.woodgrovebank.com:443... [*] Testing for SSLv2 ... Accepted SSLv2 168 bits DES-CBC3-MD5 Accepted SSLv2 128 bits RC4-MD5 [*] Testing for NULL cipher ... [*] Testing for weak ciphers (based on key length) ... [*] Testing for strong ciphers (AES) ... Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits AES128-SHA [*] Testing for MD5 signed certificate ... [*] Testing for certificate public key length ... RSA Public Key: (2048 bit) [*] Testing for certificate subject ... Subject: /C=US/ST=WA/L=Redmond/O=Microsoft/CN=tls.woodgrovebank.com [*] Testing for certificate CA issuer ... Issuer: /CN=RSACERTSRV [*] Testing for certificate validity period ... Today: Wed Oct 12 00:50:07 UTC 2011 Not valid before: Feb 14 22:52:50 2011 GMT Not valid after: Feb 14 23:02:50 2012 GMT [*] Checking preferred server ciphers ... Prefered Server Cipher(s): SSLv2 168 bits DES-CBC3-MD5 SSLv3 128 bits RC4-SHA TLSv1 128 bits AES128-SHA [-] Testing for SSLv3/TLSv1 renegotiation vuln. (CVE-2009-3555) ... [*] Testing for secure renegotiation ... Secure Renegotiation IS supported [-] Testing for TLS v1.1 and v1.2 (CVE-2011-3389 aka BEAST) ... [*] Testing for SSLv3 and TLSv1 first ... Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 [*] Testing for TLS v1.1 support ... TLS v1.1 IS supported [*] Testing for TLS v1.2 support ... TLS v1.2 IS supported [-] Testing for SSL/TLS security headers ... [*] Testing for Strict-Transport-Security (STS) header ... [*] Testing for cookies with the secure flag ... [*] Testing for cookies without the secure flag ... [-] New files created: -rw-r--r-- 1 root root 5684 2011-10-18 20:50 sslscan_tls...com:443_2011-10-18_20:49:23.log -rw-r--r-- 1 root root 2675 2011-10-18 20:50 openssl_HEAD_tls...com:443_2011-10-18_20:49:23.log -rw-r--r-- 1 root root 2408 2011-10-18 20:49 openssl_RENEG_tls...com:443_2011-10-18_20:49:23.log -rw-r--r-- 1 root root 540 2011-10-18 20:49 openssl_RENEG_tls...com:443_2011-10-18_20:49:23.err -rw-r--r-- 1 root root 523 2011-10-18 20:50 openssl_HEAD_tls...com:443_2011-10-18_20:49:23.err [-] done

If the target service does not support TLS v1.1 or v1.2 it will say "... IS NOT supported" instead. If your local openssl version does not support TLS v1.1 and v1.2, you will get the following output:

$ ./TLSSLed.sh www.example.com 443 ... [-] Testing for TLS v1.1 and v1.2 (CVE-2011-3389 aka BEAST) ... ... [*] Testing for TLS v1.1 support ... The local openssl version does NOT support TLS v1.1 [*] Testing for TLS v1.2 support ... The local openssl version does NOT support TLS v1.2 ...

Some people suggested new additions to TLSSLed based on adding checks from other already available SSL/TLS related tools, such as openssl-blacklist or ssl-cipher-check.pl. After a careful thought and detailed analysis process, TLSSLed will remain loyal to its original spirit and design, trying to keep to a minimum the prerequisites to run it (just openssl and sslscan since version 1.0). Therefore, the goal is not to make use of any additional tools from within TLSSLed except openssl and sslscan, unless there is a very critical security test that cannot be accomplished with these two. However, I'm open to implementing other missing tests using these two tools.

One of the future releases will include an associated user guide that briefly explains the different TLSSLed results and their meaning, so that you can easily understand the security implications of the findings reported by the tool without been well versed on SSL/TLS (HTTPS).

Remember, the tool is open to comments, suggestions, improvements, and new tests from the community. Do not hesitate to contact me with ideas! Thanks to Abraham Aranguren and others that want to remain anonymous for their feedback!