# Testing for Weak Transport Layer Security

|ID          |
|------------|
|WSTG-CRYP-01|

## Summary

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 [Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security) 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.

## Test Objectives

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

## How to Test

Transport layer security related issues can be broadly split into the following areas:

### Server Configuration

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.

- [SSLv2 (DROWN)](https://drownattack.com/)
- [SSLv3 (POODLE)](https://en.wikipedia.org/wiki/POODLE)
- [TLSv1.0 (BEAST)](https://www.acunetix.com/blog/web-security-zone/what-is-beast-attack/)
- [TLSv1.1 (Deprecated by RFC 8996)](https://tools.ietf.org/html/rfc8996)
- [EXPORT ciphers suites (FREAK)](https://en.wikipedia.org/wiki/FREAK)
- NULL ciphers ([they only provide authentication](https://tools.ietf.org/html/rfc4785)).
- Anonymous ciphers (these may be supported on SMTP servers, as discussed in [RFC 7672](https://tools.ietf.org/html/rfc7672#section-8.2))
- [RC4 ciphers (NOMORE)](https://www.rc4nomore.com/)
- CBC mode ciphers (BEAST, [Lucky 13](https://en.wikipedia.org/wiki/Lucky_Thirteen_attack))
- [TLS compression (CRIME)](https://en.wikipedia.org/wiki/CRIME)
- [Weak DHE keys (LOGJAM)](https://weakdh.org/)

The [Mozilla Server-Side TLS Guide](https://wiki.mozilla.org/Security/Server_Side_TLS) details the protocols and ciphers that are currently recommended.
Because of its compatibility with post-quantum ciphers, TLS 1.3 should be preferred over TLS 1.2.

#### Exploitability

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.

### Digital Certificates

#### Cryptographic Weaknesses

From a cryptographic perspective, there are two main areas that need to be reviewed on a digital certificate: The signature of the certificate itself and the key-exchange algorithm used during the TLS handshake. The following points should be considered when using classical cryptography:

- The used cipher strength should be at least 128 bits of security or higher.
- For classical signatures you should at least use RSA-3072 or ECDSA with P-256 in combination with SHA-256 or stronger.
- For a classical key exchange use ECDHE with P-256 or X25519 elliptic curves at minimum.

Additionally, both the signature and key exchange algorithm should support post-quantum cryptography. The following points should be considered:

- For post-quantum signatures you should use at least ML-DSA-44 (according to [FIPS-204](https://csrc.nist.gov/pubs/fips/204/final)) or higher.
- For post-quantum key exchanges you should use at least ML-KEM-512 (according to [FIPS-203](https://csrc.nist.gov/pubs/fips/203/final)) or higher.
- You may use hybrid ciphers such as X25519+ML-KEM-768 during the transition to post-quantum algorithms.

#### Validity

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.
    - Any certificates issued after 1st September 2020 must not have a maximum lifespan of more than [398 days](https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/).
    - The validity period of certificates will gradually be reduced to a maximum lifespan of [47 days in March 2029](https://github.com/cabforum/servercert/blob/main/docs/BR.md#11-overview).
- 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).

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 [OWASP Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#carefully-consider-the-use-of-wildcard-certificates).

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.

### Implementation Vulnerabilities

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:

- [Debian OpenSSL Predictable Random Number Generator](https://www.debian.org/security/2008/dsa-1571) (CVE-2008-0166)
- [OpenSSL Insecure Renegotiation](https://www.openssl.org/news/secadv/20091111.txt) (CVE-2009-3555)
- [OpenSSL Heartbleed](https://heartbleed.com) (CVE-2014-0160)
- [F5 TLS POODLE](https://support.f5.com/csp/article/K15882) (CVE-2014-8730)
- [Microsoft Schannel Denial of Service](https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-066) (MS14-066 / CVE-2014-6321)

### Application Vulnerabilities

As well as the underlying TLS configuration being securely configured, the a