TLS/SSL Configurations Risk Vector

⇤ Diligence Risk Category

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.

See data collection methods or the criteria for classifying findings as TLS/SSL Configurations.

Risks

• 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.^{[1] [2] [3]}
• 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.[4]

Grading

See how the TLS/SSL Configurations risk vector is graded.

Remediation

Review TLS/SSL Configuration findings.

• Update and keep server implementations of TLS/SSL (OpenSSL, LibreSSL, etc); latest versions are patched against known vulnerabilities and they have countermeasures for other attacks.
• Migrate to a minimum of TLS 1.2. Migrating to a later version of TLS is strongly encouraged. Disable SSL v2, SSL v3, TLS 1.0, and TLS 1.1.
• 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.

Finding Behavior