In this article:
What are TLS weak ciphers?
Transport Layer Security (TLS) is a widely adopted security protocol designed to facilitate privacy and data security for communications over the Internet. A primary use case of TLS is encrypting the communication between web applications and servers, such as web browsers loading a website. To secure the transfer of data, TLS uses one or more cipher suites, which is a combination of authentication or encryption. Using an old or outdated cipher makes your organization more vulnerable to attack. With an insufficient cipher, the attacker may intercept or modify data in transit.
SecurityScorecard’s process
With TLS analysis, SecurityScorecard reveals a weak cipher either through encryption protocol or public key length.
Once a certificate is found, we list the domains on the certificate, the collection target, the port, and the IP address used to provision the certificate.
This IP address may or may not belong to the organization, however it is the IP address that is used to serve the certificate.
SecurityScorecard currently flags a weak cipher when the key length is insufficient (less than 128 bits) or uses:
-
md4
-
md5
-
rc2
-
rc4
-
rsa_export
-
tls_dh_*_export
-
tls_dhe_*_export
Questions about domains and IPs appearing
Why do domains show up?
TLS issues are domain-based, and we extract that domain from the Common Name or the Subject Alternative Name (SAN) on the certificate — both valid for this purpose.
Why is a domain showing up I don’t recognize?
This is because your organization enabled your content delivery network (CDN) to serve the certificate (e.g. Incapsula, Cloudflare, or Akamai).
Why do IP addresses that are not part of my digital footprint show up?
The IP address is referenced for specifically metadata purposes. The IP address indicates where we observed the issue and to help you identify who you need to work with to resolve the issue.
When I go to my website, it doesn’t have any issues. Why?
Sometimes the CDN your organization is using serves out-of-date certificates or cipher suites on specific servers. We recommend checking the IP where we’re flagging the issue.
Why do so many issues populate?
The CDN that you are using to provision and serve the certificate (ie: Incapsula, Akamai), rotates IPs so frequently that it is causing SecurityScorecard to observe the certificate from many IPs within a window of time, thus counting each observation as a unique finding.
How to remediate TLS Weak Ciphers
Ultimately, it is recommended to configure the server to only support strong ciphers and to use sufficiently large public key sizes.
Your organization should avoid TLS versions 1.1 and below and RC4 encryption, as there have been multiple vulnerabilities discovered that render it insecure.
The best way to ensure strong transport layer security is to support TLS 1.3, which is the most secure and up-to-date version of TLS. For additional information, please investigate the article Why Use TLS 1.3?
To understand which ciphers suites your organization is using, utilize an SSL/TLS scanning tool (eg: Test TLS). Once you have the list of cipher suites, you can cross-reference with SecurityScorecard’s list of weak cipher suites.
In order to resolve the issue, your organization would have to disable the weak cipher suites, but the process differs if your organization is responsible for configuring your own service or relies on a third party. In order to understand how to disable the weak cipher suites, work with the person responsible for managing the server to change the configuration. This might be someone internally or a third party like a CDN.
If your organization uses a CDN, such as AWS Cloudfront, Akamai, Rackspace, Cloudflare, etc., please refer to their respective SSL/TLS guides on the necessary next steps.