- September 11, 2023: Separated finding messages.
- April 20, 2023: 2023 RAU weight adjustment & grading when there are no findings.
- June 16, 2022: Added “Missing intermediate certificates or untrusted root anchor” event tooltip
⇤ How is the Diligence Risk Category Calculated?
The TLS/SSL Configurations risk vector determines if security protocol libraries support strong encryption standards when making connections to other machines. Companies should have secure configurations on all servers that are hosting TLS/SSL certificates. This includes systems that are hosting the company’s website, even if they do not provide any internet-related services or its services are delivered by cloud service providers.
Impact
| Field | Description | Details & Values | |
|---|---|---|---|
| Finding Behavior | How findings behave, depending on the action taken. |
|
|
| Lifetime | The number of days a finding will impact the risk vector grade, assuming nothing changes in the future and the finding is not updated with new information. Learn why findings have a decay and lifetime period. | 60 Days | |
| No Findings | The letter grade if there are no findings or only Neutral findings for this risk vector. |
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. This is set in the center of the grading scale for computing into Bitsight Security Ratings. If there are no findings and we are temporarily unable to collect data, the most recent grade is assigned for up to 400 days before being assigned the default grade. |
|
| Refresh | The Bitsight platform regularly checks for new observations. Bitsight findings are updated as these observations change, e.g., newly observed Diligence findings or an existing finding was remediated. | ||
| Automated Scan Duration | The duration of a regularly scheduled finding refresh, as the Bitsight platform checks for new observations. | 60 Days | |
| User-Requested Refresh Duration | The duration of a user-requested refresh, which initiates a refresh of eligible findings upon request. This is recommended when a change in the finding is expected, such as when a finding has been remediated. | 3 Days | |
| Weight | Out of 70.5% in Diligence. | 15% | |
Considerations
TLS/SSL Configurations findings are evaluated as GOOD, FAIR, WARN, or BAD. Not all attributes are weighted evenly; some messages may be more serious and affect the overall finding grade more than other similarly graded messages. See finding messages.
Encryption
Ensure the version of TLS/SSL is not susceptible to any known vulnerabilities.
- A Digital Signature Algorithm (DSA) shorter than 160 bits can be broken with consumer devices. A key length of 2048 bits is recommended.
- An elliptic-curve cryptography (ECC) shorter than 160 bits can be broken with consumer devices. A key length of 224 bits is recommended.
- RSA keys shorter than 2048 bits may be insecure. According to the NIST’s Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, keys above 1024 bits and below 2048 bits are acceptable only for legacy use.
- For Simple Mail Transfer Protocol (SMTP) servers:
- To be graded as GOOD, remove support for TLSv1.0 and TLSv1.1.
- If TLSv1.2 or greater is supported, the finding is graded as FAIR.
- If TLSv1.2 or greater is not supported, the finding is graded as BAD.
- Certificates presented on the public internet should be signed by a publicly trusted certificate authority.
- Self-signed certificates and certificates with non-standard roots should either not be exposed to the general Internet or their exposure should be limited by configuring client certificate authentication.
Signature
- The server must not use a named Diffie-Hellman prime or use a Diffie-Hellman prime shorter than 2048 bits.
- The server must not support insecure encryption protocols or ciphers (e.g., the EXPORT ciphers).
- Insecure hash algorithms are graded as BAD (e.g., MD2, MD5, and SHA1).
Obsolete Protocols
Though we test for obsolete protocols (SSLv2, SSLv3, TLS 1.0, and TLS 1.1), which are all nominally graded BAD, their penalty is limited; If all four obsolete protocols are used, only a subset is penalized.
Repeated Findings
The presence of wildcards in DNS records can have an unnecessary magnification of the number of TLS/SSL Configurations findings. These repeated findings are handled as a single finding.