How is the TLS/SSL Configurations Risk Vector Assessed?

The TLS/SSL Configurations risk vector contributes to how the Diligence risk category is calculated. It 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
• Considerations
• Finding Grading

Impact

Insufficient Data

A default risk vector grade is assigned if there is insufficient or no data.

Default: – This is set in the center of the grading scale for computing into Bitsight Security Ratings.

Behavior:

• 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.
• If there are no findings and we are temporarily unable to collect data, the most recent grade is assigned for up to 340 days before being assigned the default grade.

Lifetime

Lifetime is the number of days a finding impacts the risk vector grade, assuming nothing changes in the future and the finding is not updated with new information. This is defined by the number of days a finding will impact the risk vector grade. Learn why findings have a decay and lifetime period.

Duration: 60 Days

Weight

The TLS/SSL Configurations risk vector contributes to the weight of the Diligence risk category, which aggregates the weights of all risk vectors in the category to 70.5% towards Bitsight Security Ratings.

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

• Encryption
• Signature
• Obsolete Protocols
• Repeated Findings

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

We test for the following obsolete protocols:

• SSLv2
• SSLv3
• TLS 1.0
• TLS 1.1

Obsolete protocols are penalized. The penalty is limited so that if all four obsolete protocols are used, only a subset is penalized. This is so that a server with 4 obsolete protocols has a larger impact on the rating compared to a server with only 3 protocols.

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.

Finding Grading

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.

FAIR findings for this risk vector have a negative impact on the rating.

See finding messages.