Doing your own SSL/TLS testing

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 https://www.ssllabs.com/ssltest/, 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.

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. https://www.idontexist.com:2345. 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 cipherli.st 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…

./testssl.sh --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.

• 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.

ECDHE-RSA-AES256-GCM-SHA384

• 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 cipherli.st 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.

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.

* 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)…

*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.

Fix me!

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

* Securityheaders.io 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.

*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.

*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.

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

• SSL Labs Server Tester - https://www.ssllabs.com/ssltest/
• SSL Labs Browser Tester - https://www.ssllabs.com/ssltest/viewMyClient.html
• testssl (site & github) - https://testssl.sh/ https://github.com/drwetter/testssl.sh
• Browser/version stats - http://www.w3schools.com/browsers/browsers_explorer.asp
• Mozilla SSL Configuration Generator - https://mozilla.github.io/server-side-tls/ssl-config-generator/
• Strong Cipher Configs - cipherli.st
• Scan URL and check HTTP response headers - https://securityheaders.io/
• IIS Crypto (SSL/Cipher GUI tool) - https://www.nartac.com/Products/IISCrypto
• NIST Special Publication 800-57 Part 1 Revision 4, Recommendation for Key Management Part 1: General (Jan 2016) - http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
• NIST Special Publication 800-131A Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths (Nov

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf

• PCI TLS 1.0 Disable Extension - https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
• Various HTTP/2 implementations - https://github.com/http2/http2-spec/wiki/Implementations
• OWASP TLS Cheatsheet - https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
• SSL/TLS & PKI History (timeline, very interesting!) - https://www.feistyduck.com/ssl-tls-and-pki-history/