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 (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.
Concept | Behavior |
---|---|
Duration: 60 Days |
|
A default risk vector grade is assigned. |
This is set in the center of the grading scale for computing into Bitsight Security Ratings. 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. |
Percentage (out of 70.5% in Diligence): 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
Recommendations
- Refer to the Remediation Instructions provided in the finding details. See all finding messages.
- 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.
Finding Behavior
See:
Concept | Behavior |
---|---|
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: 60 Days User-Requested Refresh Duration: 3 Days |
The old finding is replaced by a new finding.
|
References
- March 25, 2024: “No findings/low findings” changed to “insufficient data.”
- November 29, 2023: Remediation and finding behavior recommendations.
- November 10, 2023: Linked to finding messages.
Feedback
0 comments
Please sign in to leave a comment.