- November 29, 2023: Remediation and finding behavior recommendations.
- November 10, 2023: Linked to finding messages.
- August 16, 2023: New Grading & Finding Behavior sections.
The TLS/SSL Configurations risk vector determines if the used security protocol libraries support strong encryption standards when making connections to other machines. TLS/SSL is a widely used method of securing communications over the Internet.
- Incorrect or weak TLS/SSL configurations can make servers vulnerable to certain attacks, including POODLE and Heartbleed, and can allow attackers to have access to sensitive information.
- SSL and early TLS (TLS 1.0 and TLS 1.1) no longer meet the security needs of organizations, with regards to implementing strong cryptography to protect payment data over public or untrusted communications channels.
- A primary benefit and role of SSL virtual private networks (SSL VPN) is that they can operate without an explicit client. Instead, they leverage the near-ubiquity of web browsers to facilitate access. Relying on publicly trusted, third-party Certificate Authorities (CAs) for authenticating web server endpoints is considered a security best practice due to the rigors placed on certificate issuance and the built-in trust anchors present in modern browsers. SSL VPN vendor documentation often explicitly recommends VPN portals should use certificates from a trusted thirty-party CA.  
- Network appliances configured with self-signed (internally issued) or default certificates that are not rooted to a valid trust anchor:
- Devices that are connected to the Internet, but were never completely initialized or properly hardened (e.g., may have default credentials) are not designed to be used in production systems. They are prone to broad categories of weak implementations that are either less likely to occur or outright prevented by public CA signing policies.
- RSA keys automatically generated by some network appliances are prone to being weak (trivial to factor) as the result of being generated with poorly initialized entropy pools. This category of weakness is virtually non-existent in certificates that have been signed by a public CA.
This is set in the center of the grading scale for computing into security ratings.
Some findings cannot be traced back to specific companies due to the use of third party systems; such as web filters and Content Delivery Networks (CDN), that are capable of redirecting and encapsulating network traffic. Some firewalls might also be detecting and blocking external data gathering tools from getting any data.
(Out of 70.5% in Diligence)
The most common issues with TLS/SSL certificates stem from:
- A lack of appropriate signatures (no root or leaf certificate in chain, self-signed certificate, expired certificate).
- The enablement of insecure ciphers.
- Refer to the Remediation Instructions provided in the finding details. See all finding messages.
- Update and keep server implementations of TLS/SSL to a later version of TLS. The latest versions are patched against known vulnerabilities and they have countermeasures for other attacks.
- Remove all obsolete protocols (SSLv2, SSLv3, TLS 1.0, TLS 1.1). Even if business constraints require the use of TLS 1.0 or TLS 1.1, removing SSLv2 and SSLv3 is highly recommended.
- Migrate to a minimum of TLS 1.2.
- Regenerate Diffie-Hellman primes to be 2048 bits.
- Refer to the Guide to Deploying Diffie-Hellman for TLS to configure TLS securely.
- Ensure secure TLS cipher suites and key sizes are supported and use key exchange methods that support perfect forward secrecy.
- Disable support for other cipher suites that are not necessary for interoperability.
Automated: 60 Days
User-Requested: 3 Days
The old finding is replaced by a new finding.