How to remediate – SSL/TLS Versions Supported

1. Introduction

The SSL/TLS Versions Supported vulnerability shows which versions of the Secure Sockets Layer and Transport Layer Security protocols a server allows for HTTPS connections. Older versions have known weaknesses, so supporting them increases risk. This affects web servers, load balancers, and any system handling TLS traffic. A business could experience compromised confidentiality if an attacker downgrades the connection to a weaker protocol.

2. Technical Explanation

This issue occurs when a server is configured to accept older SSL/TLS versions alongside newer ones. Attackers can exploit this by attempting to negotiate a connection using a vulnerable protocol, bypassing stronger security measures. There isn’t a specific CVE associated with simply *supporting* old protocols; the risk comes from their use during an actual connection attempt. An attacker could use tools like OpenSSL s_client to force negotiation of SSLv3 or TLS 1.0 if supported by the server.

• Root cause: The server allows connections using outdated and insecure SSL/TLS protocols.
• Exploit mechanism: An attacker attempts a connection using an older, vulnerable protocol version that the server supports. If successful, they can exploit weaknesses in that protocol (e.g., POODLE for SSLv3).
• Scope: Web servers running Apache, Nginx, IIS, and other TLS-enabled services are affected if configured to support SSLv3, TLS 1.0, or TLS 1.1.

3. Detection and Assessment

You can check supported protocols using command line tools or online scanners. A thorough assessment involves testing connection negotiation with different protocol versions.

• Quick checks: Use OpenSSL to test the server’s configuration. For example: openssl s_client -connect yourserver.com:443 and look at the “Protocol” line in the output.
• Scanning: Nessus plugin ID 69851 can identify supported SSL/TLS versions. Qualys also has relevant checks. These are examples only, as scanner results vary.
• Logs and evidence: Server logs may show connection attempts using older protocols. Check access logs for TLS version information.

openssl s_client -connect yourserver.com:443 | openssl x509 -noout -dates

4. Solution / Remediation Steps

Disable support for SSLv3, TLS 1.0 and TLS 1.1 on the server. This strengthens security by forcing clients to use newer, more secure protocols.

4.1 Preparation

• Ensure no critical applications rely on older TLS versions. A roll back plan involves restoring the original configuration file.
• A change window may be required, depending on service criticality and impact assessment. Approval from the security team is recommended.

4.2 Implementation

1. Step 1: Edit your web server’s configuration file (e.g., Apache’s httpd.conf or Nginx’s nginx.conf).
2. Step 2: Locate the SSL/TLS configuration section.
3. Step 3: Set the minimum TLS version to 1.2. For example, in Apache, use SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1.
4. Step 4: Save the changes and restart your web server.

4.3 Config or Code Example

Before

SSLProtocol All

After

SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent this issue. Keeping software up-to-date and using strong configurations are key.

• Practice 1: Patch cadence ensures you apply fixes for known vulnerabilities in TLS libraries.
• Practice 2: Secure defaults configure servers with the strongest possible settings, including disabling weak protocols by default.

4.5 Automation (Optional)

# Example Ansible task to disable SSLv3/TLS1.0/TLS1.1 in Apache
- name: Disable SSLv3 and TLS 1.0/1.1 in Apache
  lineinfile:
    path: /etc/apache2/mods-enabled/ssl.conf
    regexp: '^SSLProtocol'
    line: 'SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Run openssl s_client -connect yourserver.com:443 and verify that SSLv3, TLS 1.0, and TLS 1.1 are no longer listed in the “Protocol” line.
• Re-test: Re-run the OpenSSL command from step 3 to confirm older protocols are disabled.
• Smoke test: Verify your website loads correctly and that HTTPS connections work as expected with a modern browser.
• Monitoring: Check server logs for connection errors related to unsupported protocols, which could indicate client compatibility issues.

openssl s_client -connect yourserver.com:443 | openssl x509 -noout -dates

6. Preventive Measures and Monitoring

Regular security baselines and pipeline checks help prevent this issue from reoccurring.

• Baselines: Update your server security baseline to include disabling SSLv3, TLS 1.0, and TLS 1.1.
• Pipelines: Add a check in your CI/CD pipeline to scan for insecure TLS configurations during deployment.
• Asset and patch process: Implement a regular patch review cycle to ensure timely updates of TLS libraries.

7. Risks, Side Effects, and Roll Back

Disabling older protocols may cause compatibility issues with very old clients. A roll back involves restoring the original server configuration file.

• Risk or side effect 1: Older browsers or applications might not be able to connect.
• Risk or side effect 2: Some legacy systems may require older protocols for compatibility.
• Roll back: Restore the original server configuration file and restart the web server.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for specific guidance on disabling older TLS versions.
• NVD or CVE entry: While there isn’t a single CVE, research vulnerabilities related to SSLv3, TLS 1.0 and TLS 1.1.
• Product or platform documentation relevant to the fix: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml