How to remediate – SSL Session Resume Supported

1. Introduction

The SSL Session Resume Supported vulnerability means a remote host allows restarting secure connections without a full handshake. This can allow attackers to potentially hijack existing sessions, though it doesn’t directly compromise data in transit if the underlying encryption is strong. Systems using TLS/SSL are usually affected, including web servers, email servers and VPN gateways. Impact on confidentiality is possible but depends on other factors; integrity and availability are less likely to be directly impacted.

2. Technical Explanation

This vulnerability occurs when a server enables the SSL session resumption feature, caching session IDs for faster reconnection times. An attacker can reuse a valid session ID to impersonate a legitimate user. The main precondition is that an attacker must have previously observed a valid session ID in use. There isn’t a specific CVE associated with simply *supporting* session resumption; however, related attacks like Session Hijacking (CVE-2017-3540) exploit this functionality. An example attack involves capturing a session ID during a legitimate connection and then using that ID to access the service as the original user.

• Root cause: The server maintains a cache of SSL sessions, allowing reuse of session IDs without re-authentication.
• Exploit mechanism: An attacker captures a valid session ID and uses it in subsequent connections to impersonate the legitimate user. This can be achieved through man-in-the-middle attacks or by observing network traffic.
• Scope: Affected platforms include servers running TLS/SSL, such as Apache, Nginx, IIS, OpenSSL based applications, and Java applications using SSL/TLS.

3. Detection and Assessment

You can confirm if a system is vulnerable by attempting to resume an SSL session. A quick check involves examining the server configuration for enabled session resumption features. A thorough method involves performing a full SSL handshake followed by a reconnection attempt using the obtained session ID.

• Quick checks: Use `openssl s_client -connect example.com:443` and look at the ‘Session-ID’ line in the output. If present, resumption is likely enabled.
• Scanning: Nessus plugin ID 69857 can detect SSL session resumption support. This is an example only; results should be verified manually.
• Logs and evidence: Server logs may show successful session resume events. Look for entries indicating the reuse of session IDs, though specific log formats vary by server type.

openssl s_client -connect example.com:443 | grep "Session-ID"

4. Solution / Remediation Steps

To fix this issue, disable SSL session resumption or configure it with appropriate security measures. These steps aim to reduce the risk of session hijacking without completely disabling TLS functionality.

4.1 Preparation

• Ensure you have access to revert the configuration if issues arise. A roll back plan is to restore the original configuration file.
• A change window may be needed depending on service criticality and impact. Approval from a senior administrator might be necessary.

4.2 Implementation

1. Step 1: Edit your server’s SSL/TLS configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
2. Step 2: Locate the `SSLSessionCache` directive and set it to ‘none’. For example, in Apache: `SSLSessionCache none`.
3. Step 3: Alternatively, reduce the session timeout value significantly (e.g., to a few minutes) to limit the window of opportunity for attackers.
4. Step 4: Restart your web server or relevant service to apply the changes.

4.3 Config or Code Example

Before

SSLSessionCache shm:/var/run/apache2/ssl_session_cache(512000) default

After

SSLSessionCache none

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate this vulnerability type. Least privilege reduces the impact if a session is hijacked. Input validation, while not directly applicable here, helps prevent other attacks that could lead to session ID capture. Secure headers like Strict-Transport-Security (HSTS) improve overall TLS security.

• Practice 1: Implement least privilege principles to limit the damage an attacker can cause if they hijack a session.
• Practice 2: Regularly review and update your server’s SSL/TLS configuration for best practices.

4.5 Automation (Optional)

Ansible can automate configuration changes across multiple servers. Use caution when modifying critical configurations.

---
- hosts: webservers
  tasks:
    - name: Disable SSL session resumption in Apache
      lineinfile:
        path: /etc/apache2/mods-enabled/ssl.conf
        regexp: '^SSLSessionCache'
        line: 'SSLSessionCache none'
      notify: Restart Apache
  handlers:
    - name: Restart Apache
      service:
        name: apache2
        state: restarted

5. Verification / Validation

Confirm the fix by verifying that SSL session resumption is disabled. Re-run the earlier detection method to confirm the change. Perform a basic service smoke test to ensure functionality remains intact.

• Post-fix check: Run `openssl s_client -connect example.com:443 | grep “Session-ID”`. The output should *not* contain a ‘Session-ID’ line.
• Re-test: Repeat the initial SSL connection test; no session ID should be established or reused.
• Smoke test: Verify that users can still access key website pages and services without issues.

openssl s_client -connect example.com:443 | grep "Session-ID"

6. Preventive Measures and Monitoring

Update security baselines to include disabling or configuring SSL session resumption securely. Incorporate checks in CI/CD pipelines to prevent insecure configurations from being deployed. Implement a regular patch review cycle for all TLS libraries.

• Baselines: Update your server hardening baseline (for example, CIS benchmarks) to reflect the recommended configuration for SSL session resumption.
• Pipelines: Add SAST or SCA tools to your CI/CD pipeline to detect insecure configurations in code and infrastructure as code templates.
• Asset and patch process: Review TLS library updates regularly and apply patches promptly to address known vulnerabilities.

7. Risks, Side Effects, and Roll Back

Disabling SSL session resumption may slightly increase server load due to more frequent full handshakes. If issues occur, restore the original configuration file.

• Risk or side effect 1: Increased CPU usage on the server due to more frequent full TLS handshakes.
• Risk or side effect 2: Potential compatibility issues with older clients that rely heavily on session resumption.
• Roll back: Restore the original SSL/TLS configuration file and restart your web server.

8. References and Resources

• Vendor advisory or bulletin: Consult your specific server vendor’s documentation for SSL/TLS configuration guidance.
• NVD or CVE entry: https://