How is the TLS/SSL Configurations Risk Vector Assessed?

⇤ 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
• Considerations
• Finding Grading

Impact

Considerations

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