SSL & TLS HTTPS Testing

Introduction

This article documents the process of using semi automated tools to perform SSL & TLS security assessments and how to validate the tool findings using manual testing methods.

The aim is to optimise the TLS & SSL security testing process when performing pen testing to optimise the time spent on TLS security testing.

What is TLS & SSL?

Secure Socket Layer (SSL) & Transport Layer Security (TLS) encryption are used to secure Internet and network traffic by providing communication security (encryption in transit) and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

Therefore, TLS security configuration is important and time should be spent learning and identifying the common vulnerabilities and security misconfigurations.

Has your organisation performed a Vulnerability Assessment recently? See our Vulnerability Testing services page for more information.

TLS / SSL Security Testing Tools

testssl.sh

testssl.sh is our preferred tool for testing, it covers all the required tests for TLS & SSL assessments and is regularly updated.

Installation

You can install the latest version of tesetssl.sh by performing a git clone of their repository:

git clone https://github.com/drwetter/testssl.sh.git

testssl.sh Examples

There are many testing options that can be used with testssl.sh and the options you should use will depend greatly on your testing requirements. Below are some useful examples, for an overview of testssl.sh command line options. run ./testssl.sh with no other options.

Test Everything on a Single Host and Output to console

./testssl.sh -e -E -f -p -y -Y -S -P -c -H -U TARGET-HOST

Test Everything on a Single Host and Output to HTML

./testssl.sh -e -E -f -p -y -Y -S -P -c -H -U TARGET-HOST | aha > OUTPUT-FILE.html  

Test all hosts on a Subnet and Output to HTML

./testssl.sh -e -E -f -p -y -Y -S -P -c -H -U 192.168.1.0/24 | aha > OUTPUT-FILE.html  

Same as above, but only enumerate each servers supported ciphers:

./testssl.sh -E 192.168.1.0/24 | aha > OUTPUT-FILE.html  

Screenshots of Console Output

Has your organisation performed a Web Application Penetration Test recently? See our Web Application Security Testing service page for more information.

Screenshots of HTML Output

testssl.sh Cheat Sheet

Using grep it’s possible to extend the functionality of testssl.sh to list ciphers per protocol, which is extremely useful for testing.

TLS & SSL Vulnerability Testing

Common TLS & SSL Vulnerabilities are listed below in discovered CVE date order, each vulnerability has a definition along with automated and manual (where possible) test instructions.

SWEET32 (CVE-2016-2183)

Definition

Legacy block ciphers that use a 64-bit block size such as Triple-DES (3DES) are vulnerable to a practical collision attack when used in CBC mode of operation. When CBC mode of operation is used a simple birthday attack can be used identify 64-Bit block cipher collisions. When a collision occurs it means the input is the same as the output, making it possible to perform a BEAST style attack to exfiltrate encrypted data.

The authors Karthik Bhargavan and Gaetan Leurent were able to run JavaScript in a web browser (acts as the MiTM) and send a large enough amount of data to cause a collision, then use this information to recover sessions cookies.

Testing for SWEET32

Identify if the server offers Triple-DES ciphers, if the server supports Triple-DES it’s vulnerable to SWEET32.

SWEET32 testssl.sh

Identify weak ciphers using testssl.sh:

./testssl.sh --ciphers TARGET

If the output shows Tripe DES Ciphers, like in the screenshot below, the target server is vulnerable to SWEET32:

If the output looks like the screenshot below, the server is NOT vulnerable to SWEET32:

Additionally you can enumerate all ciphers offered by a server for each protocol using:

./testssl.sh -E TARGET

Any ciphers using 3DES are vulnerable to SWEET32.

SWEET32 Nmap Testing

Nmap can also be used to enumerate the ciphers of a server, the NSE plugin will also notify if any 64-Bit block ciphers are available.

nmap --script=ssl-enum-ciphers -p443 TARGET

If you see the following in the output, 64-Bit block ciphers were discovered

warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack

Manually Testing for SWEET32

Use the Nmap enum-ciphers NSE script documented above to enumerate the ciphers

Back to Table of Contents

DROWN (CVE-2016-0800)

DROWN Definition

DROWN (Decrypting RSA using Obsolete and Weakened eNcryption), The most general variant of the DROWN attack exploits a fundamental weakness in the SSLv2 protocol that allows Man-in-The-Middle (MiTM) attackers to exploit export-grade cryptography that was introduced to comply with 1990s-era U.S. government restrictions (EXPORT grade encryption is detailed in the FREAK vulnerability description below).

Testing for DROWN

testssl.sh DROWN Testing

./testssl.sh -D TARGET

Has your organisation performed an External Penetration Test recently? See our Network Penetration Testing service page for more information.

Nmap DROWN Testing

nmap -p 443 -sV --script=sslv2-drown 

Back to Table of Contents

FREAK (CVE-2015-0204)

FREAK Definition

FREAK (Factoring RSA Export Keys), exploits a cryptographic weakness within TLS / SSL that was originally introduced by the US government decades earlier. The idea behind the RSA_EXPORT keys was to allow exports to contain encryption that could not be be broken by average computing resources but could be broken by the NSA. RSA_EXPORT keys are encrypted up 512 bits or less, which are easily crackable using modern computing resources.

The FREAK attack performs a downgrade attack (forces a server to use a weaker cipher), when combined with a Man-in-The-Middle (MiTM) type attack, this allows an attacker to capture data and break the decryption of the weak keys.

Automated testing for the FREAK Attack

testssl.sh FREAK Attack Testing

./testssl -F TARGET

Manual testing for the FREAK Attack

Manually enumerate the servers ciphers using either ./testssl.sh -E TARGET or nmap -p 443 --script=ssl-enum-ciphers TARGET, ensure none of the following ciphers supported by the server contain: EXPORT.

Example:

Back to Table of Contents

Logjam (CVE-2015-4000)

The Logjam issue exploits a flaw discovered with the way TLS protocol (1.2 and earlier) composes the Diffie-Hellman exchange. Effecting both export and non-export grade cipher suites (export ciphers explained above). The vulnerability allows a Man-in-The-Middle (MiTM) attacker to perform a downgrade attack and use the Diffie-Hellman export ciphers (DHE_EXPORT).

Does your organisation have mobile apps, have they been security tested? See our page on Mobile App Security Testing for more information.

Automated testing for Logjam

testssl.sh test for Logjam

./testssl.sh -J TARGET

Manually testing for Logjam

Disable EXPORT ciphers, Instructions are the same as the FREAK attack, documented above.

Manually enumerate the ciphers suites offered by the server, using either ./testssl.sh -E TARGET or nmap -p 443 --script=ssl-enum-ciphers TARGET.

Back to Table of Contents

Heartbleed (CVE-2014-0160)

Heartbleed Definition

A flaw was found in the way OpenSSL handled TLS and DTLS Heartbeat Extension packets that allows an attacker to disclose information from encrypted TLS / DTLS data. A malicious client could send a specially crafted TLS or DTLS Heartbeat packet to disclose a limited portion of memory per request from a connected client or server.

The disclosed portions of memory could include sensitive information such as private keys (used by service providers to encrypt data), names, usernames and passwords of actual users. Allowing attackers to potentially eavesdrop on communications, impersonate users and services and steal data.

Automated testing for Heartbleed

Testing for Heartbleed using testssl.sh:

# ./testssl.sh -B 10.0.1.159

###########################################################
    testssl.sh       2.8rc1 from https://testssl.sh/dev/
    (424cf23 2016-08-09 10:35:58 -- 1.531)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on kali:./bin/openssl.Linux.x86_64
 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")


 Start 2017-01-20 22:43:38    -->> 10.0.1.159:443 (10.0.1.159) <<--

 rDNS (10.0.1.159):      --
 Service detected:       HTTP


 Testing for heartbleed vulnerability 

 Heartbleed (CVE-2014-0160)               

VULNERABLE (NOT ok)

 Done 2017-01-20 22:43:41    -->> 10.0.1.159:443 (10.0.1.159) <<--

Testing for Heartbleed using Nmap

# nmap -p 443 --script ssl-heartbleed --script-args vulns.showall 10.0.1.159

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-01-20 22:45 EST
Nmap scan report for 10.0.1.159
Host is up (0.00028s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-heartbleed: 
|   VULNERABLE:
|   The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
|     State: VULNERABLE
|     Risk factor: High
|       OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|           
|     References:
|       http://www.openssl.org/news/secadv_20140407.txt 
|       http://cvedetails.com/cve/2014-0160/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
MAC Address: 00:0C:29:35:3D:E8 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds

Manually testing for Heartbleed

Use Metasploit to validate the existed of Heartbleed, using the verbose setting will show the Heartbleed exposed memory leak.

msf> use auxiliary/scanner/ssl/openssl_heartbleed
msf> set rhosts TARGET-ADDRESS
msf> set verbose true
msf> run

Back to Table of Contents

POODLE SSLv3 (CVE-2014-3566)

POODLE Definition

The POODLE attack (Padding Oracle On Downgraded Legacy Encryption) was discovered by Google's Security Team on October 14, 2014. The vulnerability exploits the way SSLv3 handles padded bytes when used with (cipher block chaining) CBC mode of operation.

The flaw allows a Man-in-The-Middle (MiTM) attacker to decrypt a selected byte of a cipher text in as few as 256 SSLv3 connections, if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections.

Automated Testing For POODLE

Testing for POODLE using Nmap

# nmap -p 443 --script ssl-poodle --script-args vulns.showall 10.0.1.159

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-01-20 22:50 EST
Nmap scan report for 10.0.1.159
Host is up (0.00037s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-poodle: 
|   VULNERABLE:
|   SSL POODLE information leak
|     State: VULNERABLE
|     IDs:  CVE:CVE-2014-3566  OSVDB:113251
|           The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
|           products, uses nondeterministic CBC padding, which makes it easier
|           for man-in-the-middle attackers to obtain cleartext data via a
|           padding-oracle attack, aka the "POODLE" issue.
|     Disclosure date: 2014-10-14
|     Check results:
|       TLS_RSA_WITH_AES_128_CBC_SHA
|     References:
|       http://osvdb.org/113251
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
|       https://www.imperialviolet.org/2014/10/14/poodle.html
|_      https://www.openssl.org/~bodo/ssl-poodle.pdf
MAC Address: 00:0C:29:35:3D:E8 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds

Testing for POODLE using testssl.sh

./testssl.sh -O 10.0.1.159

###########################################################
    testssl.sh       2.8rc1 from https://testssl.sh/dev/
    (424cf23 2016-08-09 10:35:58 -- 1.531)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on kali:./bin/openssl.Linux.x86_64
 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")


 Start 2017-01-20 22:52:59    -->> 10.0.1.159:443 (10.0.1.159) <<--

 rDNS (10.0.1.159):      --
 Service detected:       HTTP


 Testing for SSLv3 POODLE (Padding Oracle On Downgraded Legacy Encryption) 

 POODLE, SSL (CVE-2014-3566)               VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)

 Testing for TLS_FALLBACK_SCSV Protection 

 TLS_FALLBACK_SCSV (RFC 7507), experim.    Downgrade attack prevention NOT supported

Manual Testing for POODLE

The version of openssl that ships with Kali no longer support SSLv3. Use the binary within testssl.sh/bin/openssl.Linux.x86_64 to perform manual SSLv3 testing.

./openssl.Linux.x86_64 s_client -ssl3 -connect 10.0.1.159:443

If the handshake completes, the server is vulnerable to POODLE.

Example output for a server that is vulnerable to POODLE (certificate snipped out of the response):

---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 1398 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 0450660185C7B2623CB2145A1C6655BDD8CC281F882C3B9E0ED35E88360639BA
    Session-ID-ctx: 
    Master-Key: 6A56AC01754D9441ACFD6C0B9E534E33450CD2F0E0D619F235E2ACC1780CFD86E769B9AE82D0D5AAA4C62B295B5BB598
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1484971085
    Timeout   : 7200 (sec)
    Verify return code: 9 (certificate is not yet valid)
---

If the server is not vulnerable to POODLE the handshake will fail, giving an error such as:

CONNECTED(00000003)
28395584:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1475:SSL alert number 40
28395584:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---

Back to Table of Contents

CCS Injection Vulnerability (CVE-2014-0224)

CCS Injection Definition

A weakness exists within certain versions of OpenSSL that allows clients and servers to be forced, via a specially crafted handshake packet to use weak keying material for communication. Allowing A Man-in-The-Middle attacker to decrypt and modify traffic between a client and a server.

Affected OpenSSL Versions:

• OpenSSL before 0.9.8za
• OpenSSL 1.0.0 before 1.0.0m
• OpenSSL 1.0.1 before 1.0.1

Source: https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0224

Automated Testing for CCS Injection

testssl.sh CCS Injection Testing

./testssl.sh -I TARGET

Nmap CCS Injection Testing

nmap -p 443 --script=ssl-ccs-injection TARGET

Back to Table of Contents

POODLE TLS (CVE-2014-8730)

POODLE TLS Definition

Due to TLS padding being a subset of SSLv3's, it's possible to re-purpose the POODLE attack against TLS. TLS is very strict about how its padding is formatted, however some TLS implementations do not perform the check for padding structure after decryption. Implementations that do not are vulnerable to the POODLE attack even with TLS.

Source: https://blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls

Testing for POODLE TLS

testssl.sh POODLE TLS Testing

Same as testssl.sh instructions above for POODLE SSL

Nmap POODLE TLS Testing

Same as Nmap instructions above for POODLE SSL

Back to Table of Contents

BREACH (CVE-2013-3587)

BREACH Attack Definition

BREACH stands for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext. Similar to CRIME breach exploits a vulnerability within HTTP compression, allowing an attacker to identify if text exists within a page.

Basic example of how the BREACH attack works

When text repetition occurs on a page, deflate will remove repetitive terms helping reduce the size of a page. This can be used to identify existing page content, an example below on a web application that shows the username of the currently logged in user reflected within the page:

1. Enter a username you think will not exist into a search parameter
2. Note the size of the returned page
3. Send another search request for a username you think exists
4. Note the size of the returned page, if the username matched the logged in user the page size will be reduced by deflate

No traffic is actually "decrypted" by analysing the size of the responses it's possible to predict the text

In order for the BREACH attack to successfully exfiltrate data there must be a mechanism to reflect user input within the rendered page and the server must support HTTP compression.

Automated Testing for BREACH

Testing for BREACH using testssl.sh

./testssl.sh -T TARGET

Manual Testing for BREACH

 
openssl s_client -connect TARGET:443

Enter the following to identify if the server uses compression:

GET / HTTP/1.1
Host: TARGET
Accept-Encoding: compress, gzip

If the server returns garbled meta characters like in the screenshot below, the server supports compression and is vulnerable to BREACH:

If the target web server does not return compressed data output it is not vulnerable to BREACH and compression is disabled.

Back to Table of Contents

RC4 CVE-2013-2566

The RC4 algorithm used in the TLS protocol and SSL protocol, has many single-byte biases. Making it easier for remote attackers to conduct plaintext-recovery attacks via statistical analysis of the ciphertext in a large number of sessions that use the same plaintext.

Automated RC4 Testing

testssl.sh RC4 Testing

./testssl.sh -4 TARGET

Manual RC4 Testing

Manually enumerate the servers ciphers using either ./testssl.sh -E TARGET or nmap -p 443 --script=ssl-enum-ciphers TARGET, ensure none of the following ciphers supported by the server use RC4.

Back to Table of Contents

CRIME (CVE-2012-4929)

CRIME Attack Definition

CRIME is a TLS 1.2 vulnerability that allows Man-In-the-Middle (MiTM) attackers to identify encrypted data and (potentially) perform session hijacking. An attacker can identify encrypted data by examining the size of the ciphertext while introducing multiple payloads from the browser, when a character is matched within the header it's size will differ allowing an attacker to workout session cookies. No data is actually decrypted using the CRIME attack, a weakness within the way TLS 1.2 handles compression allows an attacker to identify when the character exists within the header by comparing the returned size.

Automated Testing for CRIME

Testing for CRIME with testssl.sh

./testssl.sh -C TARGET

Manually Testing for CRIME

The openssl client used by Kali appears to no longer allow TLS 1.2 compression. If you test with this version of openssl, the response will always be "Compression: NONE" even if the target server had TLS 1.2 compression enabled. Use the openssl.Linux.x86_64 binary that ships with testssl.sh to overcome this issue.

./bin/openssl.Linux.x86_64 s_client -connect 10.0.1.158:443

Example Output - Not Vulnerable to CRIME

If server is NOT vulnerable to CRIME. "Compression: None" indicates compression is disabled on the server and it is not vulnerable to CRIME.

Compression: NONE

Example Output - Vulnerable to CRIME

If the server IS vulnerable to CRIME:

Compression: zlib compression

Back to Table of Contents

Renegotiation (CVE-2009-3555)

TLS/SSL Renegotiation Vulnerability Definition

In 2009 a vulnerability was discovered that exploits the TLS & SSL protocols renegotiation process, allowing an attacker to insert data into the start of the session and compromise it's integrity.

Conditions

The following conditions must be met for this vulnerability to be exploitable:

• Server must not support secure renegotiation
• Server must allow client side renegotiation

Automated Testing for Renegotiation

Tests for both secure renegotiation and client side renegotiation.

# ./testssl.sh -R 10.0.1.159

###########################################################
    testssl.sh       2.8rc1 from https://testssl.sh/dev/
    (424cf23 2016-08-09 10:35:58 -- 1.531)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on kali:./bin/openssl.Linux.x86_64
 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")


 Start 2017-01-21 00:04:30    -->> 10.0.1.159:443 (10.0.1.159) <<--

 rDNS (10.0.1.159):      --
 Service detected:       HTTP


 Testing for Renegotiation vulnerabilities 

 Secure Renegotiation (CVE-2009-3555)      not vulnerable (OK)
 Secure Client-Initiated Renegotiation     not vulnerable (OK)

 Done 2017-01-21 00:04:31    -->> 10.0.1.159:443 (10.0.1.159) <<--

Manually Testing for Renegotiation

Testing for Secure Renegotiation

openssl s_client -connect TARGET:443

Example when Secure Renegotiation is not enabled:

---
SSL handshake has read 1606 bytes and written 503 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:

Example when Secure Renegotiation is enabled:

---
SSL handshake has read 1560 bytes and written 495 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:

Testing for Client Initiated Secure Renegotiation

openssl s_client -connect TARGET:443

Type:

HEAD / HTTP/1.1 
R

Hit return, if you see the response:

HEAD / HTTP/1.1 
R
RENEGOTIATING

The server allows client renegotiation.

If you see the response:

HEAD / HTTP/1.1 
R
RENEGOTIATING
139681067286040:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:

The server does not support client renegotiation.

Back to Table of Contents

TLS & SSL Certificates

The server certificate while not required for encryption should be assessed for configuration errors and weak cryptographic signing, below is a check list for certificate checking:

Pull the target servers certificate using:

openssl s_client -connect TARGET:443 | openssl x509 -noout -text

Certificate Cheat Sheet

Back to Table of Contents

HTTP Security Headers

What are HTTP Security Headers?

HTTP Security Headers, if configured correctly can provide additional security features for your domain. Below is an overview of the primary HTTP security headers:

HTTP Security Headers can be examined using Burp Suite, Curl or testssl.sh (any many other tools).

Examining HTTP Security Headers with Curl

curl -s -D - TARGET -o /dev/null

Example Output:

HTTP/1.1 301 Moved Permanently
Date: Mon, 23 Jan 2017 16:15:51 GMT
Server: Apache
Content-Security-Policy: default-src 'self' *.target
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Location: TARGET
Cache-Control: max-age=3600
Expires: Mon, 23 Jan 2017 17:15:51 GMT
Vary: Accept-Encoding
Content-Length: 233
Content-Type: text/html; charset=iso-8859-1

Examining HTTP Security Headers with testssl.sh

./testssl.sh -H

HTTP Security Header Cheat Sheet

Back to Table of Contents

Conclusion

We hope this article has clarified the testing process for some of the more common TLS & SSL vulnerabilities. If we missed anything or you have any suggestions or techniques we would love to hear from you in the comment section below.