SSL/TLS Service Supports Weak Protocol

Name: SSL/TLS Service Supports Weak Protocol
Identifier: tls_weak_protocol
Severity: High
Factor: Network Security

Summary

The Issue type SSL/TLS Service Supports Weak Protocol (tls_weak_protocol) identifies the endpoints offering any of the following SSL/TLS protocols: SSLv2, SSLv3, TLS1.0, TLS1.1.

Description

Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over a computer network, typically the internet. It ensures privacy and data integrity between applications by encrypting the data transmitted between them. TLS establishes a secure connection through a process of negotiation between the client and server, known as the TLS handshake. During this handshake, the parties agree on encryption algorithms, exchange cryptographic keys, and verify each other's identities. Once the secure connection is established, data transmitted between the client and server is encrypted, making it inaccessible to unauthorized parties who may attempt to intercept or tamper with it. TLS is widely used to secure various internet protocols, including web browsing, email, instant messaging, and file transfers, and safeguards sensitive information from eavesdropping and unauthorized access.

Risk

One significant risk associated with Transport Layer Security (TLS) is the potential for vulnerabilities in the protocol itself or in its configuration. These vulnerabilities could be exploited by malicious actors to intercept, manipulate, or eavesdrop on sensitive data transmitted over the network. Improperly configured TLS settings or weak cryptographic algorithms may weaken the security of the communication channel, leaving it susceptible to attacks such as man-in-the-middle attacks, session hijacking, or decryption of encrypted data. Failure to promptly update TLS libraries and configurations to address known vulnerabilities can further exacerbate these risks, potentially leading to data breaches, privacy violations, and reputational damage for affected organizations.

Recommendations

- Implement strong cryptographic algorithms and key lengths recommended by security standards.

- Regularly update TLS libraries and configurations to patch known vulnerabilities.

- Configure TLS settings to enforce mutual authentication between client and server.

- Utilize certificate pinning to ensure trust in SSL/TLS certificates.

Additional Information

The severity in Scoring 3.0 is High. It is based on breach risk and determined by SecurityScorecard based on SecurityScorecard data using ML/AI. See Scoring Methodology Whitepaper

Note: Server configuration examples can be found on the following 3rd Party tools:
https://ssl-config.mozilla.org/ (Intermediate and Modern configurations)
for nginx: ssl_protocols TLSv1.2 TLSv1.3;
for Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
Documentation for IIS: TLS/SSL Overview (Schannel SSP) ; Registry Changes - Server 2008+ / Server 2003 and older

The endpoint is determined by the combination of target and port. Therefore, a finding can be detected on a IP target endpoint as well as a Domain target endpoint. Domain target endpoint leverages the usage of SNI (present in the observation of the finding). 
From an outside scan perspective, an IP target endpoint and a Domain target endpoint are distinct as virtual domain configuration may be in use. As such, SecurityScorecard considers those as distinct findings, not duplicates.

IP Target endpoint example:

Domain Target endpoint (SNI) example:

Self testing

You may validate the SSL/TLS protocol version offered by the endpoint using the following 3rd Party tools. All can be used to confront contradictory results. However when comparing results, ensure that the endpoint scanned by each is exactly the same information and matching the SecurityScorecard finding. (ex IPtarget:port or DomainSNItarget:port).

• Test TLS (based on https://testssl.sh/)
  https://testtls.com/18.160.10.37/443
  https://testtls.com/api.securityscorecard.io/443
   

• OpenSSL (example below for TLS1.1)

  openssl s_client -showcerts -connect 18.160.10.37:443 -tls1_1

  openssl s_client -showcerts -connect api.securityscorecard.io:443 -tls1_1

  openssl s_client -showcerts -connect api.securityscorecard.io:990 -tls1_1 (implicit TLS)

  openssl s_client -showcerts -connect api.securityscorecard.io:21 -starttls ftp -tls1_1 (explicit TLS

• sslscan

  sslscan 18.160.10.37:443

  sslscan api.securityscorecard.io:443

  

• nmap  using ssl-enum-ciphers script

  nmap -sV --script ssl-enum-ciphers -p 443 18.160.10.37

  nmap -sV --script ssl-enum-ciphers -p 443 api.securityscorecard.io

  

Remediation

SecurityScorecard allows the removal of findings if either of the following is true:

• Endpoint configuration has been changed, the Weak Protocols are not offered anymore.
  => Select the finding and then click on the "Fixed" button, "technical_remediation".
• The endpoint has been closed and therefore not offering any of the Weak Protocols.
  => Select the finding and then click on the "Fixed" button, "technical_remediation".
• After verification (using the methods above for example), the endpoint defined in the finding does not offer any of the Weak Protocols in the contrary of what SecurityScorecard is stating.
  => Select the finding and then click on "Other resolutions" --> "I cannot reproduce this issue and I think it’s incorrect", "false_positive".

Note: If the Weak Protocols cannot be removed (for example the configuration of the endpoint cannot be changed due to business requirements or the service doesn't provide this feature), it is SecurityScorecard policy that the finding remains as-is, and you can add a Public Issue Comment to provide context to anyone following your scorecard. See https://support.securityscorecard.com/hc/en-us/articles/360056396471-Commenting-on-Issues for more information.