SSL & TLS

HTTPS Testing The definitive guide for SSL / TLS security testing by Aptive.

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 pen testing services to help spend less time on TLS / SSL security testing.

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.

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.

Command Description Check for PFS and list supported ciphers per protocol testssl.sh --quiet -E TARGET | grep -E 'DHE-DSS-AES128-GCM-SHA256|DHE-DSS-AES128-SHA256|DHE-DSS-AES128-SHA|DHE-DSS-AES256-GCM-SHA384|DHE-DSS-AES256-SHA256|DHE-DSS-AES256-SHA|DHE-DSS-CAMELLIA128-SHA256|DHE-DSS-CAMELLIA128-SHA|DHE-DSS-CAMELLIA256-SHA256|DHE-DSS-CAMELLIA256-SHA|DHE-DSS-SEED-SHA|DHE-RSA-AES128-CCM8|DHE-RSA-AES128-CCM|DHE-RSA-AES128-GCM-SHA256|DHE-RSA-AES128-SHA256|DHE-RSA-AES128-SHA|DHE-RSA-AES256-CCM8|DHE-RSA-AES256-CCM|DHE-RSA-AES256-GCM-SHA384|DHE-RSA-AES256-SHA256|DHE-RSA-AES256-SHA|DHE-RSA-CAMELLIA128-SHA256|DHE-RSA-CAMELLIA128-SHA|DHE-RSA-CAMELLIA256-SHA256|DHE-RSA-CAMELLIA256-SHA|DHE-RSA-CHACHA20-POLY1305-OLD|DHE-RSA-CHACHA20-POLY1305|DHE-RSA-SEED-SHA|ECDHE-ECDSA-AES128-CCM8|ECDHE-ECDSA-AES128-CCM|ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-AES128-SHA256|ECDHE-ECDSA-AES128-SHA|ECDHE-ECDSA-AES256-CCM8|ECDHE-ECDSA-AES256-CCM|ECDHE-ECDSA-AES256-GCM-SHA384|ECDHE-ECDSA-AES256-SHA384|ECDHE-ECDSA-AES256-SHA|ECDHE-ECDSA-CAMELLIA128-SHA256|ECDHE-ECDSA-CAMELLIA256-SHA384|ECDHE-ECDSA-CHACHA20-POLY1305-OLD|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-AES128-SHA256|ECDHE-RSA-AES128-SHA|ECDHE-RSA-AES256-GCM-SHA384|ECDHE-RSA-AES256-SHA384|ECDHE-RSA-AES256-SHA|ECDHE-RSA-CAMELLIA128-SHA256|ECDHE-RSA-CAMELLIA256-SHA384|ECDHE-RSA-CHACHA20-POLY1305-OLD|ECDHE-RSA-CHACHA20-POLY1305|Hexcode|SSLv|TLS 1' Test for BEAST, will list per protocol testssl.sh --quiet --beast TARGET Display certificate information testssl.sh --quiet --server-defaults TARGET List ciphers that offer no encryption per protocol testssl.sh --quiet -E TARGET | grep -Ei 'NULL|ANON|Hexcode|SSLv|TLS 1' Test for LUCKY13 per protocol testssl.sh -E TARGET | grep -iE "CBC|Hexcode|SSLv3|TLS 1" List all the supported SSL / TLS protocols testssl.sh --quiet --protocols FREAK / LOGJAM



Test for EXPORT grade ciphers and list per protocol testssl.sh -E TARGET | grep -iE "EXPORT|Hexcode|SSLv3|TLS 1" Test for RC4 list per protocol testssl.sh -E TARGET | grep -iE "RC4|Hexcode|SSLv3|TLS 1" Test for CRIME testssl.sh -C TARGET Test for BREACH testssl.sh -T TARGET Test for secure renegotiation



Test for client initiated secure renegotiation testssl.sh -R TARGET Check HTTP response headers testssl.sh -H TARGET

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) <> 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) < 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:

Enter a username you think will not exist into a search parameter Note the size of the returned page Send another search request for a username you think exists 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) <> 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

Name Description Identify Certificate Issuer Insure the certificate authority (CA) is from a trusted source, self signed certificates should not be used as they allow for man in the middle attacks (unless they are internal and signed against an internal CA). Signature Algorithm The algorithm used to insure the certificates integrity, you should insure this is cryptographically secure and not using MD5 (known to be insecure) or SHA1. Public Key The key length should be long enough to insure it cannot be compromised, the minimum should be 2048 bit. Not Before Certificate start date. Not After Certificate end date. Subject

Subject Alternative Name Subject should list the DNS name the certificate relates too, if this is incorrect browsers will throw an error. Subject Alternative Name should list DNS names for wildcard certificates, all DNS names for this certificate should be listed.

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

Name Definition Strict-Transport-Security (HSTS) HTTP Strict Transport Security (HSTS) security header forces web browsers or clients to communicate with servers only through HTTPS connections. HSTS ensures the connection only uses HTTPS and prevents Man-in-The-Middle (MiTM) attacks, downgrade attacks and cookie-hijacking. HSTS is Trust on First Use (TOFU), meaning it must send at least one insecure connection over HTTP to the host to transfer the secure header. The HSTS preload list is an effort to provide browsers with a list of sites that support HSTS to avoid the initial insecure connection. Content-Security-Policy (CSP) Content-Security-Policy (CSP) is a HTTP Security Header that helps mitigate the risk of certain types of data injection attacks such as XSS (Cross-site-scripting). CSP allows website administrators to eliminate or mitigate XSS by by defining a policy that stipulates what locations browsers should trust and allow script execution from. X-Frame-Options The X-Frame-Options header prevents website content being rendered within an <iframe>, <frame> or an <object>. By preventing content being rendered within these elements, sites can use the X-Frame-Options to prevent clickjacking. X-XSS-Protection An older HTTP Security Header that enables XSS protection in Internet Explorer, Chrome and Firefox. Although this functionality is now provided by CSP by blocking inline JS, this header can still provide protection when used with older browsers that don't support CSP. X-Content-Type-Options Prevents MIME-sniff type attacks by forcing the MIME type specified by the Content-Type.

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.