Doing your own SSL/TLS testing

Author Will Hunt

Date 5 September 2016

This post will detail how to carry out SSL/TLS scans against your assets and how to interpret the output. It forms part of our series of guides that aim to help you prepare for a penetration test.

This means that the SSL/TLS related low hanging fruit that would ordinarily be identified from a similar scan carried out by a third party pentesting company, can be carried out and issues remediated in-house before getting a pentest.

This is good because:

  • Your penetration testing company can focus on the more specialised areas of testing
  • Better value for money on your penetration testing engagement
  • No (or a lot fewer) SSL/TLS issues in resulting report! (Got to be good for whoever you have to show it to!)

We will cover two types of test, an online assessment using the well known SSL Labs scanner, and a standalone scan using testssl, a tool that forms part of the arsenal of many pentesters for SSL/TLS testing. In terms of the checks carried out (and subsequent remediation), the output from both these methods will be very similar.

SSL/TLS testing is a little tricky as environmental factors play a big part in the security of the overall configuration and implementation. For example client browsers need to be considered (it’s not just ensuring the server side config is secure) and if the application is internally facing only, older/legacy browsers may be more likely to exist which could introduce connectivity issues.

For externally facing assets, SSL Labs scanner is often a convenient choice however, if you’re testing internally without outbound access you will need an autonomous tool which is where testssl comes in. To be honest, I use testssl against external applications as well simply because of the importance of dual tool verification.

The first section using the online scanner will be purely instructional for execution, the subsequent testssl section will include high level details on how to fix the issues you may identify, and the last two sections will cover some final thoughts and useful resources.

SSL Labs Online Scanner

Quick and easy. Go to, tick the ‘Do not show the results on the boards’ button (so your results aren’t made public), enter the URL you wish to scan, and click submit. For the purposes of this guide, I’ll put my finger in the air and arbitrarily pick a completely random site that just happens to have an A+ rating as an example…



The above screenshot is truncated but there’s a multitude of information available about the SSL/TLS configuration. Ultimately though the result takes you back at school, an A+ is very good, an F isn’t! So if your results aren’t great and you want to avoid detention after work, let’s move onto the next section and have a look at what can be identified from these scans and how to remediate any issues found.


Scanning with testssl

Download and prep

First of all, download the scanner . Running the tool as is will use a custom openssl compilation that includes a lot of the old ciphers and configs you’ll want to check for. As more recent openssl libraries often phase out a lot of this stuff you run the risk of missing potential issues if you tell the tool to use your existing library. An example is shown below where testssl was downloaded to my Kali box. The first run points to my current Kali library which is version 1.2.0h comprising circa 124 ciphers, and the second run uses the in-built testssl 1.0.2-chacha compilation which includes circa 183 ciphers.

Unless you are running a customised openssl library and you are aware of any legacy ciphers that may be missing (and accept the risk), don’t assign the –openssl switch and run the tool as is.

testssl1 - Copy


On your marks, get set…

Adding a –wide switch before the URL will provide more verbose info about certain tests carried out, and the following test and screenshots will be based on a –wide scan, however it’s not mandatory and everything discussed can be easily identified without it. Additionally if you’re testing an internal service on a non-standard port, adding “:” to the end of the URL will allow you to assign it, e.g. The following sections will be broken down in the areas testssl scans in order, which are:

  • Testing protocols
  • Testing standard cipher lists  (grouped into high level categories)
  • Testing robust perfect forward secrecy
  • Testing server preferences
  • Testing server defaults
  • Testing HTTP header response
  • Testing vulnerabilities
  • Testing all 183 locally available ciphers  (number depending on ciphers in openssl library used)
  • Browser Simulations

Each section will show an example screenshot of testssl output (although from an A+ site we won’t be seeing too many negative results! :-) ) followed by a brief background section on what’s being tested, then wrapping up with a Fix me! section. Providing specific remedial action for every issue for every web server would be somewhat laborious (and the post would quickly turn into a book that could never be updated quickly enough) however where applicable, further info for commonly used configs is provided. Some tests in different sections also overlap a little, e.g. weak ciphers are flagged in more than one check, so don’t be surprised if you see issues crop up again.

If you’re unfortunate enough to find yourself lacking in the SSL/TLS department following a scan, you should still have more than enough info here to start climbing your way out of your insecure crypto hole! If you want a very quick and dirty reference for generic secure configs, the Mozilla SSL Configuration Generator and provide some across a number of web servers. They cover off several (but by no means all) of the issues outlined later, however, standard caveat, don’t blindly copy any configs into a production environment without thoroughly testing first!

Ok, on your marks…get set…

./ --wide https://www.<insert-hopefully-very-secure-site>.com

…Go! - Section 1 -  Testing Protocols


Background Info

This section tests which protocols are supported.  We don’t need to go into massive detail here, needless to say you should not support SSLv2 or SSLv3 as there are several weaknesses. SSLv2 has been around for two decades and it didn’t take long to identify weaknesses. SSLv3 was considered secure until the Padding Oracle on Downgraded Legacy Encryption (POODLE) attack was identified in 2014 (POODLE is covered in a later section). Please note that under certain circumstances POODLE was also found to affect TLS 1.0.

TLS is the way forward though. Nearly all modern browsers support at least TLS 1.0, and in the last couple of years the following core browsers support TLS 1.1 and TLS 1.2.

  • Chrome v22+
  • Firefox v27+ (in v23+ but disabled by default)
  • IE v11+ (in v8+ but disabled by default)
  • Opera v9+ (in v8 but disabled by default)
  • Safari v9+
  • Safari Mobile v5+

Even though TLS 1.0 is still very frequently used, support for all three TLS protocols will allow the negotiation of more secure TLS 1.2 connections where available, as typically the most secure protocol will be negotiated first.

Version tolerance refers to the inability of a server to negotiate a TLS version it doesn’t understand, e.g. the client can support up to TLS 1.2 and the server can only support up to 1.1, but the server can subsequently think “Ok, 1.2 is higher than 1.1, so the client must be able to support 1.1”, and can downgrade to 1.1. In our test the ‘downgraded to 1.2’ refers to the (nearing completed) development of TLS 1.3, so testssl tries negotiating this (as well as other larger numbers) to ensure the server doesn’t throw a wobbly and downgrades properly. If the server couldn’t handle the downgrade the connection would fail all together.

SPDY/NPN checks support for Google’s experimental SPDY (not an acronym!) protocol and Next Protocol Negotiation (NPN) was replaced by Application Layer Protocol Negotiation (ALPN) which is a TLS extension required by HTTP/2, the next major rework of the HTTP protocol! . Just to confuse matters more, despite having evolved over time, HTTP/2 is based largely on SPDY.

In our test, HTTP/2 (one implementation of which is referred to as h2) is advertised but not offered, therefore ALPN by consequence is also not offered. For reference, if these and SPDY were offered you’d likely see an output similar to this…

SPDY/NPN   h2, spdy/3.1, http/1.1 (advertised)
HTTP2/ALPN h2, spdy/3.1, http/1.1 (offered)

Fix me!

If your output looks like the screenshot above, you’re all good for the first bout of checks. But here’s a recap of what to do if you see problems.

Failed CheckFix?
SSLv2Completely drop support for SSLv2
SSLv3Completely drop support for SSLv3
TLS 1.0
Check  browser compatibility above, update if necessary. Check OS/web
server support*  ***
TLS 1.1
Check  browser compatibility above, update if necessary. Check OS/web
server support*
TLS 1.2
Check  browser compatibility above, update if necessary. Check OS/web
server support*
Version tolerance
Server side implementation error - needs to be fixed by vendor.
Browser voluntary protocol downgrade required to ensure strongest
common connection is used.
Susceptible to CRIME attack (discussed later). Not an inherent
security risk by itself.
Not a security risk if currently unsupported. Windows 10 / Server 2016
  • IIS 10 support HTTP/2. Apache 2.4.17 supports HTTP/2** |

*Further reading on TLS compatibility in Windows/IIS . TLS 1.1 and 1.2 were introduced in Apache 2.2.31, update to most recent version. Minimum of OpenSSL 1.0.1 is also required for TLS 1.1+, however OpenSSL support for 1.0.1 branch will cease on 31/12/2016. Consider 1.0.2 or 1.1.0 branches.

**Further reading for Windows users here and here, and Apache instructions can be found here.

***At the end of 2015 the PCI Security Standards Council restated that all processing and third party entities must support TLS 1.1 by June 2016 although they later extended support of TLS 1.0 until June 2018. i.e. after June 2018 you can’t support TLS 1.0 and remain PCI DSS compliant!

Section 2 - Testing standard cipher lists


Background Info

This section tests support for various cipher suites that testssl groups into categories. We only want to support ‘high grade encryption’ which currently is considered to be 128 bit ciphers as a minimumhowever, NIST guidelines (p. 51) state that 112 bits of cryptographic strength is sufficient. Further discussion regarding this can be found in the ‘Battle of the bits’ section nearer the end of this post. Please note that a cipher, e.g. ECDHE-RSA-AES256-GCM-SHA384, is not to be confused with a protocol, e.g. SSLv3 or TLS 1.2. A brief description of the main components of a cipher suite, for example the one previously mentioned, can be found below.


  • Key exchange algorithm used for handshake authentication*
  • Encryption algorithm used to encrypt message stream
  • Message authentication code (MAC) used to create message digest, a hash of each block in message stream

* In this case signed with RSA, may also see algorithms signed with ECDSA or DSS.

For reference we can also have a look at the source code (below) to further identify what testssl calls high grade encryption, and see how these categories relate to the openssl spec cipher strings. A further breakdown of these can be found here. This section doesn’t require too much more explanation because if testssl flags the support any of the weaker ciphers (except for potentially 3DES, see section 9 background info), drop support for them!


Fix me!

For Apache (and some other common servers), secure configs can be obtained from the Mozilla SSL Configuration Generator and as noted earlier, both of which will provide secure configs for cipher support.

For Windows/IIS, further information about ciphers and where to configure them can be found here, and IIS Crypto is a useful GUI tool that can assist in configuring supported ciphers.

Either way you will want to remove support for any cipher suites that are less than 128 bits.

Section 3 - Testing robust perfect forward secrecy


Background Info

This section tests whether the server supports robust perfect forward secrecy (PFS). The ‘robust’ is dependant on whether most browsers support PFS or whether only modern browsers support it (in which case it would just be PFS).

First, a brief background on PFS. Following the connection and handshake between client and server, the resulting master secret (used to encrypt communications after the initial connection) is protected by the server’s private key. If an attacker were to record encrypted communications between a client and server, then at a later stage compromise the server’s private key, they would be able to decrypt any previously recorded communications. PFS is the counter to this. By using a random public key each time a connection is made (using ephemeral Diffie-Hellman (DH) keys), the compromise of the server’s private key for a given communication means that past communications are still secure. Ephemeral Diffie-Hellman keys signed by a digital signature algorithm (a common one being RSA) are notated by EDH, or more commonly, DHE.

The Elliptic curves offered section at the bottom of the screenshot refers to the support of another implementation of the DH key exchange mechanism. The difference between DH and elliptic curve DH (ECDH) is that in the DH, factors of the secret key generation are based on integer calculations, whereas in ECDH they are based on points on an elliptic curve. That’s as deep as this post will cover this as it’s a huge area with some deep maths.

Fix me!

Support ephemeral Diffie-Hellman keys! Ensure DHE / ECDHE cipher variants are present in your supported cipher suite list, suitably high up the list so that they are preferred.

Section 4 - Testing server preferences


Background Info

This section simply identifies whether or not the server has a preferred protocol and cipher, and what the negotiated cipher is. The above screenshot has been truncated as showing the complete list would be messy, however we can identify that TLS 1.2 is the negotiated protocol (and therefore preferred, after identifying common support between server and client), with the ECDHE-RSA-AES128-GCM-SHA256 cipher suite. This is a strong preferred protocol/cipher combination and as such, testssl is happy that it is secure. Confusingly, the protocol order in the above screenshot is not listed in preference order, i.e. servers won’t try and negotiate TLS 1 ciphers first, then TLS 1.1 etc. It’s simply a list of supported protocol/cipher combinations.

The server cipher order check compares the list of offered ciphers by the client, with the list shown below.

section4-1 - Copy

Fix me!

Any issues found with the negotiated protocol/cipher will be to do lack of server support for new protocols/ciphers. Any issues identified in the cipher order section will be the presence of weak ciphers (which is covered in the ‘Fix me!’ areas of sections 1, 2 and 5). Issues here would be the preferred negotiation of a weak protocol/cipher suite. As with previous guidance, ensure your server supports TLS and that any supported weak ciphers are dropped. If your server only supports TLS 1.0 testssl will flag it, so ensure that support for 1.1 and 1.2 is also present.

Section 5 - Testing server defaults


Background Info

A number of things are going on in this section, all of which detail aspects of the ‘server hello’ message, the second stage of the SSL/TLS handshake after the server receives the ‘client hello’. The best way to go through all this is to provide some brief detail around each aspect in a table.

testssl checkDescription
TLS Extensions (standard)
Shows TLS extensions server supports. Extensions add functionality to
Session Tickets RFC 5077
Server can give client a session ticket to resume session quickly
(abbreviated handshake) **
SSL Session ID support
Whether the server supports session IDs (this method and
aforementioned session tickets resume TLS sessions)
TLS clock skew
Clocks are used for certificate validation (certificate expiry and
certificate revocation list (CRL) expiry)
Signature algorithmThe algorithm used to sign the SSL certificate
Server key size
Public key and size, should be minimum of 2048 bits, many now go
straight to 4096.
Fingerprint / Serial
Fingerprint (thumbprint) is a hash of the whole cert. Serial number is
specified by certificate authority (CA).
Common name (CN)
Common Name, typically or If CN doesn’t match URL, browser error
occurs showing mismatch.
subjectAltName (SAN)Where alternative names can be assigned
Contains certificate issuer details. Will flag as ‘NOT ok’ if it
fails, possibly with ‘self-signed’ or ‘chain incomplete’
Trust (hostname)
Compares server name against cert (CN and SAN), also checks if Server
Name Indication (SNI) TLS extension is required for checking.
Chain of trust
Where more than one cert is found, checks each cert, verifies return
code for errors
EV cert (experimental)Checks for presence of Extended Validation (EV) cert
Certificate Expiration
SSL certificate expiration date, if expired users will see a browser
error stating this when connecting. testssl warns if < 60 days.
# of certificates providedDisplays number of certs in chain
Certificate Revocation ListLocation of certificate revocation list (CRL) of issuer
Location of Online Certificate Status Protocol (OCSP) of issuer.
Alternative to CRL’s for checking revocation status.
OCSP stapling
Checks whether OCSP stapling is offered. Saves client having to
contact CA to check for certificate revocation as server adds
(‘staples’) time stamped specific CA response during initial

* Further reading on many of the TLS extensions used can be found here

** Session tickets need to be rotated every 86400 seconds (24 hours) or less, or potential to void PFS. Further reading here and here.

Ok, now we’ve got a brief understanding of what’s being tested, let’s run through what to do if any of the checks fail (where applicable)…

Failed checkFix?
TLS Extensions (standard)
Not a check - shows supported TLS extenstions. Further info on TLS
extension can be found
Session Tickets RFC 5077
If session resumption is desired, enable session tickets/ID
SSL Session ID support
session resumption is desired, enable session tickets/ID
TLS clock skewSync the clock
Signature algorithm
Will fail is signed with weak algorithm (MD5/SHA1). Replace with
Server key size
Will fail if < 2048 bits. Replace with minimum 2048 bit key, or
4096 if desired.
Fingerprint / SerialNot a check - just pulling information from cert
Common name (CN)
Not a check - testssl reads whatever’s in field (browser errors will
occur if CN doesn’t match URL).
subjectAltName (SAN)Not a check - testssl reads whatever’s in field
IssuerReplace certificate with one from a valid CA
Trust (hostname)If cert doesn’t match URL, replace cert.
Chain of trust
Replace relevant certificate in chain with valid/secure cert from CA
EV cert (experimental)N/A - Not a security risk if not present
Certificate Expiration
If certificate expires soon, replace with cert from CA as soon as
# of certificates providedN/A - Informational
Certificate Revocation ListNeed to support CRL, OCSP or both.*
OCSP URINeed to support CRL, OCSP or both.*
OCSP staplingNeed to support CRL, OCSP or both.*

*Even if only one is supported, it is preferable to support both. OCSP is a lower computational overhead.

Section 6 - Testing HTTP header response


Background Info

This section analyses the headers found in the HTTP responses from the server (if the service runs HTTP). Some SSL tools don’t analyse this information so it’s a good value add in terms of an overall analysis of the security posture of the server. Again, we’ll provide a little detail followed by some general remedial action.

testssl checkDescription
HTTP Status Code
Shows the HTTP response code from the server (number and description).
Checks for redirection and if insecure (HTTP) shows warning.
HTTP clock skewNo check - just displays difference.
Strict Transport Security
Shows HTTP Strict Transport Security (HSTS) header parameters if
HSTS helps prevent protocol downgrade attacks (forcing HTTPS over
Public Key Pinning
Checks for HTTP Public Key Pinning (HPKP). This aids websites in
resisting impersonation by attackers using fraudulent certs. If
present shows number of keys, expiry, relevant domains and matching
host key.
Server bannerDisplays the server banner from the web server if present
Application banner
Displays X-Powered-By, X-AspNet-Version,
X-Version, Liferay-Portal, X-OWA-Version,
MicrosoftSharePointTeamServices headers, if present
Identifies cookies in response (if present), and checks for
Secure and HttpOnly flags.
Security headers: X-Frame-Options
Just reports whether header is present. Indicates whether or not a
browser can render pages in frames , iframes or objects.
Security headers: X-XSS-Protection
Just reports whether header is present. Enables/disables cross-site
scripting (XSS) protection. 0 = off, 1 = on.
Security headers: X-Content-Type-Options
Just reports whether header is present. IE and Chrome are
compatible. Use with value of nosniff to prevent browser
from mome-sniffing responses away from one declared by server. Aids
in reduced exposure to drive-by-downloading.
Security headers: X-UA-Compatible
Just reports whether header is present. Allows author to choose the
version of IE the page should be rendered as. Recommended to enable
if you support IE9/8.
Reverse Proxy banner
Reports following server side proxy banners if present. Via,
X-Cache, X-Squid, X-Varnish,
X-Server-Name, X-Server-Port, X*-forwarded*.

Fix me!

…aaaaand here’s a few ideas to solve the problems in this section where applicable.

Failed checkFix?
HTTP Status Code
Returns status code unless insecure redirection. If insecure,
implement HTTPS everywhere and check additional security is present
(secure cookies, HSTS etc)
HTTP clock skewSync clock.
Strict Transport Security
Implement HSTS.
Read more.
Public Key Pinning
Further reading on HPKP implementations can be found
Server banner
Remove server banner.
URL Rewrite
can do this for IIS, and
is further reading for Apache and other web servers.*
Application banner
Remove miscellaneous headers. Above links for server banner also
assist with many of these.*
Add secure and HttpOnly flags to cookies if missing
Security headers: X-Frame-OptionsRemove X-Frame-Options header. Above links for server banner also
assist with many of these.*
Security headers: X-XSS-ProtectionRemove X-XSS-Protection header. Above links for server banner also
assist with many of these.*
Security headers: X-Content-Type-OptionsRemove X-Content-Type  header. Above links for server banner also
assist with many of these.*
Security headers: X-UA-Compatible
Possibly leave if you support legacy browsers, otherwise remove.*
Reverse Proxy bannerRemove any identified banners

* is a great site that will take a  URL and quickly flag risky HTTP response headers

Section 7 - Testing vulnerabilities


Background Info

This section checks the server against several common vulnerabilities to identify if it is susceptible to any of them. Each vulnerability tested has copious amounts of associated reading, so only a brief outline of the nature of the vulnerability will be provided, along with the relevant CVE/RFC links.

Heartbleed (CVE-2014-0160)
Allows attacker to read RAM of affected system and eavesdrop on
encrypted communications. See
for further details.
CSS (CVE-2014-0224)
ChangeCipherSpec (CCS) injection vulnerability. Improper handling of
CCS messages during session negotiation could provide MitM vector by
downgrading cipher spec.
Secure Renegotiation (CVE-2009-3555)
Server doesn’t properly associate renegotiation handshakes with
existing connection resulting in MitM vector
Secure Client-Initiated Renegotiation
Checks to see if server supports insecure client-initiated
renegotiation (possible on OpenSSL 0.9.8k and earlier). Possible to
support secure and insecure client renegotiation as server
will use secure if offered, but will also accept legacy renegotiation
too. Further reading
CRIME, TLS (CVE-2012-4929)
Compression Ratio Info-leak Made Easy (CRIME). Data leakage when
data is compressed before encryption. If an attacker
can repeatedly inject/mix predictable data into stream prior to
encryption, they can observe resulting encrypted stream they could
extract unknown data from it. Further reading
BREACH (CVE-2013-3587)
Extension on CRIME. BREACH attacks HTTP responses (that use HTTP
compression) by analysing length and deriving secrets from responses.*
Further reading
here and
POODLE , SSL (CVE-2014-3566)
Allows active MitM to decrypt content on an SSLv3 connection due to
protocol downgrade/fallback when negotiating a TLS session. More
recent devlopments show POODLE to potentially affect TLS also. Further
reading here and
TLS_FALLBACK_SCSV (RFC 7507), experimental
Servers that didn’t support offered version during negotiation needed
to fallback or else they’d crash. In this check testssl states ‘*This isn’t a vulnerability check per se, but checks for the
existence of the countermeasure to protect against protocol
downgrade attacks.*’
FREAK (CVE-2015-0204), experimentalFactoring RSA Export Keys (FREAK) allows attackers to intercept
HTTP connections and forces them to use weakened encryption which
the attacker can then break to eavesdrop. Further reading
DROWN (CVE-2016-0800,
CVE-2016-0703)Decrypting RSA with Obsolete and Weakened eNcryption (DROWN). If a server supports SSLv2 and shares private
keys with other servers that allow SSLv2 connections, attacker can
decrypt TLS connections on affected servers. Further reading
LOGJAM (CVE-2015-4000), experimental
Allows MitM to downgrade vulnerable TLS connections to 512-bit export
grade cryptography. Attacker can then read/modify data transmitted.
Similar (but not identical) to FREAK attack. Further reading
BEAST (CVE-2011-3389)
Browser Exploit Against SSL/TLS (BEAST). Client side vulnerability, IV
blocks used to mask plain text data prior to encryption can be
predicted by MitM. Further reading
RC4 (CVE-2013-2566,
Attacks on RC4 stream cipher involving weaknesses in pseudo-random
generation of biases mixed into stream, allowing plain text recovery.
Further reading
and here.

*The BREACH vulnerability here is present because gzip HTTP compression is enabled. If a specific page within a domain is passed in the URL then testssl will only test that page, otherwise it defaults to “/”. 4ARMED are aware of this and disable HTTP compression on sensitive pages, as well as taking additional mitigating security measures. Business justifications for leaving compression enabled is due to performance overheads and concerns about subsequent end user experience.

Fix me!

Below is a table providing some remedial action thoughts where applicable.

Heartbleed (CVE-2014-0160)
Update to minimum of OpenSSL 1.0.1g but preferably newer*
CSS (CVE-2014-0224)
Update to minimum of OpenSSL 1.0.1h but preferably newer*
Secure Renegotiation (CVE-2009-3555)
Upgrade to latest version of OpenSSL
Secure Client-Initiated RenegotiationUpgrade to latest version of OpenSSL
CRIME, TLS (CVE-2012-4929)
If on Chrome/Firefox update to latest version and disable TLS
compression. Further reading
BREACH (CVE-2013-3587)
If vulnerable hard to fully fix, various options include CSRF token
defence, chunked encoding, referer check mitigation, length hiding,
rate limiting requests etc. Further reading
here and
POODLE , SSL (CVE-2014-3566)
Completely drop support for SSLv3. Review potential affected vendors
TLS_FALLBACK_SCSV (RFC 7507), experim
Protection against protocol downgrade attacks. Client and server need
to support TLS_FALLBACK_SCSV for it to work. Upgrade to OpenSSL 1.0.1j
but preferably newer.
FREAK (CVE-2015-0204)
Disable support for TLS export cipher suites, ensure PFS is enabled,
refer to
Mozilla SSL Configuration Generator
/ for
reference. Update browser to latest version, update OpenSSL to latest
DROWN (CVE-2016-0800,
CVE-2016-0703), experimental
Completely drop support for SSLv2. Further reading
LOGJAM (CVE-2015-4000), experimental
Disable export cipher suites and use a minimum 2048-bit DH group.
[Here]( target=)
is a guide that can assist.
BEAST (CVE-2011-3389)
As client-side vuln, best server can do is mitigate clients from
becoming vulnerable. Modern browsers aren’t vulnerable. Supporting RC4
is an option but RC4 is weak in it’s own right (as detailed above) and
this post doesn’t endorse it’s use. Configure server to use TLS 1.1 or
1.2 only (this would cause big issues as clients using the popular TLS
1.0 wouldn’t connect).***
RC4 (CVE-2013-2566,
CVE-2015-2808)Drop support for RC4 cipher suites.

*Recommended minimum OpenSSL installations superseded by 1.0.1j in TLS_FALLBACK_SCSV fix, therefore upgrade to minimum of 1.0.1j, but preferably newer. Please note support for OpenSSL 1.0.1 branch will cease on 31/12/2016. Consider 1.0.2 or 1.1.0 branches.

**In certain products POODLE can also affect TLS 1.0.

***Test shown in screenshot shows potential vulnerability for BEAST due to TLS 1.0 support. This is a business justification for 4ARMED as disabling TLS 1.0 would prevent a large number of older browsers still in use from connecting.

Section 8 - Testing all 183 locally available ciphers



Background Info

This phase tests every locally available cipher (in our custom 1.0.2-chacha installation that’s 183 ciphers) to establish what is supported. Note here that 183 ciphers are not listed because testssl by default won’t show failed (unsupported) ciphers.  If you wish to see every attempted cipher you would need to add –show-each in the command line. These ciphers were already actually shown in the truncated screenshot from section 4. If there were any issues here they would of course, in testssl fashion, highlight them in red, or yellow for a warning.


Fix me!

Flagged issues here will be the presence of weak cipher suites (or aspects thereof e.g. strong encryption with weak key exchange). Remedial action here is what’s been covered in the ‘Fix me!’ areas of sections 1, 2 and 5. As always, ensure check that the removal of weak ciphers is inline with business risk and that unwanted consequences don’t occur (e.g. user base lost to removal of 3DES, covered in the ‘Battle of the Bits’ section later).

Section 9 - Browser simulations


Background Info

The final phase of tests provide a very useful insight into whether client browsers can successfully negotiate a connection with your server. This is great because much of the unknown in SSL/TLS vulnerabilities (client side browsers) can here be tested for us. Obviously if you support weak protocols (that by now I’m sure you’ve dropped support for!) then they may be listed here if no stronger connection could be negotiated. This is therefore a very quick way of identifying that the majority of clients should (hopefully) have no issues connecting. There isn’t a ‘Fix me!’ section for this stage because the table is informational, based on the culmination of data acquired from previous tests and browser support data collected here. A couple of things to note though…

  • As you can see several browsers still negotiate a TLS 1.0 connection. This ties in with 4ARMED’s justification for leaving TLS 1.0 enabled (noted in section 7 - potential BEAST vulnerability). Dropping TLS 1.0 would mean the applicable browsers would no longer connect and therefore this data is useful to assess the software your clients use.
  • Note the No connection for IE6/7/8 on XP. This is due to the lack of support for 3DES ciphers, again a business justification but if you have a large number XP with IE6/7/8 users then you may wish to leave support (more on this in next section).

Battle of the bits

There is sometimes disparity between tools and guidelines, and the Data Encryption Standard (DES), or more accurately, the Triple DES (3DES, TDES or 3TDEA) cipher suites fall into this crack. We mentioned in section 2 that we wanted to support a minimum of 128 bit ciphers, however guidelines stated that 112 bit was still sufficient. We had support for 3DES disabled however let’s look at how testssl would identify 3DES ciphers should they have existed.

section2-2 - Copy

This is a testssl scan of a server that support one 3DES cipher suite, however other unsupported 3DES suites have also been listed. You’ll note that 3DES is classed as being 168 bits in stength. 168 bits is greater than our 128 bit minimum, so why are 3DES flagged? What testssl doesn’t stipulate is the effective strength of 3DES.

We won’t go into detail about the different keying implementations of 3DES, however to provide a little background as to the numbers under dispute here are some things to note…

  • 3DES uses three unique keys during encryption, each providing 56 bits of cryptographic strength (56 x 3  = 168 bits of strength)
  • Due to attacks on 3DES the strength of the 168 bit key is reduced to that of the work required to exhaust a 112 bit key

A word of warning, the above link outlining ‘meet-in-the-middle’ attacks on 3DES involves some serious maths so it’s not a read for the faint hearted! Going back to the guidelines referenced and linked above, NIST state that 112 bits is sufficient (for now) for encryption, the below table is taken from NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key Management (updated January 2016).


So in terms of the number of bits, NIST take 3DES attacks into account, however testssl doesn’t. What can we take from this? When I discover 3DES cipher support I always include it in reports, but as an informational level point (referencing NIST). I don’t class it as an ‘issue’ per say, firstly because of NIST guidelines, but it also comes back to browser support - you only stand to lose XP users running very old browsers by dropping support for 3DES, which is likely a very small number of users.

I’d obviously want to ensure my clients’ security is as strong as it absolutely can be, unless discussions reveal that the server does support lots of legacy users! (and that would be their call). I therefore generally still recommend that a minimum of 128 bit cipher suites are used. Debate aside, it’s only a matter of time before 3DES are dropped, 128 bit ciphers move up the table so to speak, and the bar will be raised that bit higher thereafter.

Final Thoughts

So there we have it. A run down of how SSL Labs scanner, and more prominently, testssl (just one tool among many) can be used to assess the SSL/TLS configuration and resulting security posture of your services. Ensuring you’re as secure as you can be from potential threats is absolutely paramount today however, the blanket caveat to all this is of course to ensure that you don’t blindly drop support left right and centre for everything one tool flags as being an issue as you could affect operations within your environment by doing so. Remediate weaknesses absolutely but ensure all factors in your environment are considered first and that actions are taken in accordance with business risk and requirements.

Another point to note that ties in with this is that, at the end of 2015 the PCI Security Standards Council restated that all processing and third party entities must support TLS 1.1 by June 2016 but have extended support of TLS 1.0 until June 2018. Whilst that’s nearly 2 years away, it’s something that organisations who require compliance to PCI DSS need to consider now to efficiently implement the transition in time.

Useful Resources


About The Author

Will Hunt

Will is a Security Consultant and CREST Registered Tester with a wealth of experience in both penetration testing and digital forensics. He has delivered strategic and technical training in both areas and has an insatiable thirst for knowledge. You can tweet him @stealthsploit.

Related Articles