How to remediate – SSL Cipher Suites Supported

1. Introduction

The SSL Cipher Suites Supported vulnerability means a remote service is using Secure Sockets Layer (SSL) to encrypt communications. This allows attackers to potentially intercept and decrypt sensitive data if weak ciphers are enabled. Systems offering any network service, such as web servers, email servers, and VPN gateways, can be affected. A successful exploit could compromise the confidentiality of data in transit.

2. Technical Explanation

The vulnerability occurs when a server advertises support for outdated or insecure SSL/TLS cipher suites. An attacker can then negotiate a connection using one of these weak ciphers, making it easier to decrypt the communication. Exploitation requires a network connection to the vulnerable service and the ability to initiate an SSL/TLS handshake.

• Root cause: The server is configured to accept cipher suites that are known to be insecure or have weaknesses.
• Exploit mechanism: An attacker uses tools like OpenSSL’s s_client command to connect to the server and negotiate a connection using a weak cipher suite. They can then intercept and decrypt traffic. For example, an attacker might use `openssl s_client -connect targethost:443 -cipher ‘ADH-RC4-MD5’` to attempt a connection with a vulnerable cipher.
• Scope: Affected platforms include any operating system or application that supports SSL/TLS, such as Apache, Nginx, Microsoft IIS, and OpenSSL libraries.

3. Detection and Assessment

• Quick checks: Use `openssl s_client -connect targethost:443` and review the cipher suite list in the output.
• Scanning: Nessus plugin ID 64285 can identify supported SSL ciphers. This is an example only, other scanners may also provide this information.
• Logs and evidence: Server logs might show the negotiated cipher suite during connection attempts. Check access logs for details of TLS handshakes.

openssl s_client -connect targethost:443 | openssl x509 -text

4. Solution / Remediation Steps

4.1 Preparation

• Ensure you have access to the server’s SSL/TLS configuration files. A roll back plan is to restore from backup or revert the configuration changes.
• A change window may be required for services with high availability requirements. Approval should be sought from the relevant team lead.

4.2 Implementation

1. Step 1: Edit the server’s SSL/TLS configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
2. Step 2: Remove any insecure cipher suites from the configuration. Focus on removing ciphers using RC4, DES, MD5, and those with export-grade encryption.
3. Step 3: Prioritize strong, modern cipher suites like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
4. Step 4: Restart the affected service to apply the changes.

4.3 Config or Code Example

Before

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ALL

After

SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:TLS_AES_128_GCM_SHA256

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact if a service is compromised. Patch cadence ensures timely updates to address known vulnerabilities. Secure defaults provide a baseline of secure configuration options.

• Practice 1: Implement least privilege principles, limiting access to SSL/TLS configuration files and keys.
• Practice 2: Maintain a regular patch cadence for all server software, including OpenSSL libraries.

4.5 Automation (Optional)

If suitable, provide a small script or infrastructure code that applies the fix at scale. Only include if safe and directly relevant.

# Example Ansible task to update SSLCipherSuite in Apache config
- name: Update SSLCipherSuite
  lineinfile:
    path: /etc/apache2/mods-enabled/ssl.conf
    regexp: '^SSLCipherSuite'
    line: 'SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:TLS_AES_128_GCM_SHA256'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Run `openssl s_client -connect targethost:443 | openssl x509 -text` and confirm that only strong cipher suites are listed in the output.
• Re-test: Re-run the Nessus scan (plugin ID 64285) to verify no vulnerable ciphers are reported.
• Smoke test: Test basic website functionality or email sending/receiving to ensure services operate as expected.
• Monitoring: Monitor server logs for TLS handshake errors, which could indicate configuration issues.

openssl s_client -connect targethost:443 | openssl x509 -text

6. Preventive Measures and Monitoring

• Baselines: Update your server security baseline to enforce the use of only approved, strong cipher suites (for example, using CIS benchmarks).
• Pipelines: Integrate SAST tools into CI/CD pipelines to scan configuration files for insecure SSL/TLS settings.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Incorrect configuration could prevent all SSL/TLS connections. Mitigation is to carefully review the changes and have a roll back plan in place.
• Roll back: Restore the original server configuration file from backup, or revert the specific