How to remediate – TLS Next Protocols Supported

1. Introduction

The TLS Next Protocols Supported vulnerability means a service advertises which protocols it supports for use with TLS connections. This can indicate misconfiguration, potentially allowing attackers to attempt unsupported protocols and gather information about the system. It typically affects web servers, email servers, and any application using TLS. A successful attack could lead to information disclosure or denial of service.

2. Technical Explanation

This vulnerability occurs when a server advertises support for Next Protocol Negotiation (NPN) or Application-Layer Protocol Negotiation (ALPN) without properly validating the requested protocol. An attacker can query the server to see which protocols are advertised, even if the server doesn’t actually support them. Nessus does not attempt TLS negotiation during this check; it only reports what is advertised.

• Root cause: The service incorrectly advertises supported TLS protocols.
• Exploit mechanism: An attacker sends a TLS client hello requesting various protocols to identify those falsely advertised by the server.
• Scope: Web servers (Apache, Nginx), email servers (Postfix, Exchange) and any application using OpenSSL or similar libraries are potentially affected.

3. Detection and Assessment

Confirming a system is vulnerable involves checking which protocols it advertises over TLS. A quick check can be done with `openssl s_client`. A thorough method uses a vulnerability scanner.

• Quick checks: Use the following command, replacing with the target server address. Look at the “Advertised protocols” section in the output.

  openssl s_client -connect :443

• Scanning: Nessus plugin ID 16089 can identify this issue, but it only reports advertised protocols. Other scanners may have similar checks.
• Logs and evidence: Server logs may show attempts to negotiate unsupported protocols, though this is not always reliable.

4. Solution / Remediation Steps

Fixing this involves ensuring the server accurately advertises supported TLS protocols or disabling NPN/ALPN if they are not required.

4.1 Preparation

• Ensure you have access to the server’s TLS configuration files. A rollback plan is to restore the original configuration file.
• A change window may be needed, depending on service criticality and impact of downtime. Approval from a senior administrator might be required.

4.2 Implementation

1. Step 1: Review your server’s TLS configuration file (e.g., Apache’s httpd.conf or Nginx’s nginx.conf) for NPN/ALPN settings.
2. Step 2: Remove any unsupported protocols from the advertised list, or disable NPN/ALPN entirely if not needed.
3. Step 3: Restart the web service to apply the changes.

4.3 Config or Code Example

Before

SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite HIGH:!aNULL

After

SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite HIGH:!aNULL

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of a successful attack, while secure defaults reduce misconfiguration risk.

• Practice 1: Least privilege – restrict service accounts to only necessary permissions.
• Practice 2: Secure defaults – configure TLS with minimal supported protocols and strong cipher suites.

4.5 Automation (Optional)

# Example Ansible task to update SSL configuration file
- name: Update SSL protocol settings
  lineinfile:
    path: /etc/nginx/nginx.conf
    regexp: 'SSLProtocol All'
    line: 'SSLProtocol TLSv1.2 TLSv1.3'
  notify: Restart Nginx

5. Verification / Validation

Confirm the fix by checking that only supported protocols are advertised over TLS and verifying service functionality.

• Post-fix check: Run `openssl s_client -connect :443` again. The output should show only TLSv1.2 and TLSv1.3 (or your configured supported versions).
• Re-test: Re-run the Nessus scan (plugin ID 16089) to confirm it no longer reports unsupported protocols.
• Smoke test: Verify that users can still access websites or services using HTTPS.
• Monitoring: Monitor server logs for TLS negotiation errors, which could indicate a regression.

openssl s_client -connect :443 | grep "Advertised protocols"

6. Preventive Measures and Monitoring

Update security baselines to include correct TLS configuration settings. Implement checks in CI/CD pipelines to prevent misconfiguration during deployment.

• Baselines: Update your server hardening baseline or CIS control to require only supported TLS protocols.
• Pipelines: Add a static analysis check to your CI pipeline that validates the TLS configuration file against known good settings.
• Asset and patch process: Review TLS configurations regularly as part of your asset management and patching cycle.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Older browsers may not support newer TLS versions, causing connection errors.
• Risk or side effect 2: Incorrect configuration could lead to service downtime.
• Roll back: Restore the original server configuration file and restart the web service.

8. References and Resources

• Vendor advisory or bulletin: Check your server vendor’s website for specific TLS configuration guidance.
• NVD or CVE entry: No specific CVE is associated with simply advertising protocols, but related vulnerabilities exist.
• Product or platform documentation relevant to the fix: https://technotes.googlecode.com/git/nextprotoneg.html