TLS/SSL Configurations Risk Vector

The TLS/SSL Configurations risk vector is part of the Diligence risk category. It 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 (a security vulnerability that takes advantage of Internet and security software clients' fallback to SSLv3 and allows attackers to decrypt traffic to domains that support SSLv3) and Heartbleed (a security vulnerability in the OpenSSL cryptography library), 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.

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

Insufficient Data

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

Default:

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.

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

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%

Remediation

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.

Resources

• Findings
• Finding Messages

Recommendations

• Refer to the Remediation Instructions provided in the finding details. See all finding messages.
• See TLS/SSL Finding Remediation & Remediation Verification.
• 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.
• See the guide for what to do after remediation.

Finding Behavior

Rescan

The Bitsight platform regularly checks for new observations. Findings are rescanned as these observations change, e.g., newly observed Diligence findings or an existing finding was remediated.

Automated Scan Duration: 60 Days

User-Requested Rescan Duration: 3 Days

Remediated Findings

The behavior of findings if they are remediated.

Behavior: The old finding is replaced by a new finding.

• Newly discovered findings immediately impact the grade and are assigned its lifetime.
• Remediated records with a certificate serial number identical to the previous record are considered to be the same, remediated finding, and are assigned their lifetimes.
• For remediated and rescanned findings, the newest remediated finding replaces any past finding and is assigned its lifetime. The previous finding immediately stops impacting the grade.
• Updated findings stop impacting the grade when an asset is taken offline. The findings associated with offline assets are marked closed within 3 days when a user-requested rescan is requested.