Testing for Weak Transport Layer Security (WSTG-CRYP-01)
Last updated
Last updated
WSTG-CRYP-01
When information is sent between the client and the server, it must be encrypted and protected in order to prevent an attacker from being able to read or modify it. This is most commonly done using HTTPS, which uses the protocol, a replacement for the older Secure Socket Layer (SSL) protocol. TLS also provides a way for the server to demonstrate to the client that they have connected to the correct server, by presenting a trusted digital certificate.
Over the years there have been a large number of cryptographic weaknesses identified in the SSL and TLS protocols, as well as in the ciphers that they use. Additionally, many of the implementations of these protocols have also had serious vulnerabilities. As such, it is important to test that sites are not only implementing TLS, but that they are doing so in a secure manner.
Validate the service configuration.
Review the digital certificate's cryptographic strength and validity.
Ensure that the TLS security is not bypassable and is properly implemented across the application.
Transport layer security related issues can be broadly split into the following areas:
There are a large number of protocol versions, ciphers, and extensions supported by TLS. Many of these are considered to be legacy, and have cryptographic weaknesses, such as those listed below. Note that new weaknesses are likely to be identified over time, so this list may be incomplete.
().
Anonymous ciphers (these may be supported on SMTP servers, as discussed in )
CBC mode ciphers (BEAST, )
It should be emphasised that while many of these attacks have been demonstrated in a lab environment, they are not generally considered practical to exploit in the real world, as they require a (usually active) MitM attack, and significant resources. As such, they are unlikely to be exploited by anyone other than nation states.
From a cryptographic perspective, there are two main areas that need to be reviewed on a digital certificate:
The key strength should be at least 2048 bits.
The signature algorithm should be at least SHA-256. Legacy algorithms such as MD5 and SHA-1 should not be used.
As well as being cryptographically secure, the certificate must also be considered valid (or trusted). This means that it must:
Be within the defined validity period.
Be signed by a trusted certificate authority (CA).
This should either be a trusted public CA for externally facing applications, or an internal CA for internal applications.
Don't flag internal applications as having untrusted certificates just because your system doesn't trust the CA.
Have a Subject Alternate Name (SAN) that matches the hostname of the system.
The Common Name (CN) field is ignored by modern browsers, which only look at the SAN.
Make sure that you're accessing the system with the correct name (for example, if you access the host by IP then any certificate will be appear untrusted).
Certificates can also leak information about internal systems or domain names in the Issuer and SAN fields, which can be useful when trying to build up a picture of the internal network or conduct social engineering activities.
Over the years there have been vulnerabilities in the various TLS implementations. There are too many to list here, but some of the key examples are:
As well as the underlying TLS configuration being securely configured, the application also needs to use it in a secure way. Some of these points are addressed elsewhere in this guide:
Mixed active content is when active resources (such as scripts to CSS) are loaded over unencrypted HTTP and included into a secure (HTTPS) page. This is dangerous because it would allow an attacker to modify these files (as they are sent unencrypted), which could allow them to execute arbitrary code (JavaScript or CSS) in the page. Passive content (such as images) loaded over an insecure connection can also leak information or allow an attacker to deface the page, although it is less likely to lead to a full compromise.
Note: modern browsers will block active content being loaded from insecure sources into secure pages.
Many sites will accept connections over unencrypted HTTP, and then immediately redirect the user to the secure (HTTPS) version of the site with a 301 Moved Permanently redirect. The HTTPS version of the site then sets the Strict-Transport-Security header to instruct the browser to always use HTTPS in future.
There are a large number of scanning tools that can be used to identify weaknesses in the SSL/TLS configuration of a service, including both dedicated tools and general purpose vulnerability scanners. Some of the more popular ones are:
It is also possible to carry out most checks manually, using command-line looks such as openssl s_client or gnutls-cli to connect with specific protocols, ciphers or options.
When testing like this, be aware that the version of OpenSSL or GnuTLS shipped with most modern systems may will not support some outdated and insecure protocols such as SSLv2 or EXPORT ciphers. Make sure that your version supports the outdated versions before using it for testing, or you'll end up with false negatives.
It can also be possible to performed limited testing using a web browser, as modern browsers will provide details of the protocols and ciphers that are being used in their developer tools. They also provide an easy way to test whether a certificate is considered trusted, by browsing to the service and seeing if you are presented with a certificate warning.
The details the protocols and ciphers that are currently recommended.
Any certificates issued after 1st September 2020 must not have a maximum lifespan of more than .
Some certificates may be issued for wildcard domains (such as *.example.org), meaning that they can be valid for multiple subdomains. Although convenient, there are a number of security concerns around this that should be considered. These are discussed in the .
(CVE-2008-0166)
(CVE-2009-3555)
(CVE-2014-0160)
(CVE-2014-8730)
(MS14-066 / CVE-2014-6321)
However, if an attacker is able to intercept this initial request, they could redirect the user to a malicious site, or use a tool such as to intercept subsequent requests.
In order to defend against this type of attack, the site must use be added to the .
(various scripts)