How to remediate – Secure HyperText Transfer Protocol (S-HTTP) Detection

1. Introduction

The Secure HyperText Transfer Protocol (S-HTTP) Detection vulnerability means a web server is accepting connections encrypted using an old and rarely used protocol. S-HTTP was defined in 1999 but wasn’t widely adopted. Using it creates security risks because older code tends to have more flaws. This affects any system running a vulnerable web server, potentially impacting the confidentiality of data transmitted, with a lower risk to integrity or availability.

2. Technical Explanation

The root cause is that the web server still supports S-HTTP alongside modern protocols like HTTPS. An attacker could attempt to connect using S-HTTP to exploit potential weaknesses in its implementation. While not actively exploited, it presents a risk due to the age and limited testing of the protocol. There are no known CVEs associated with this specific detection, but the underlying issue relates to insecure cryptographic implementations (CWE-301). An attacker could attempt a man-in-the-middle attack if S-HTTP is used instead of HTTPS.

• Root cause: The web server has not disabled support for the obsolete S-HTTP protocol.
• Exploit mechanism: An attacker attempts to establish an S-HTTP connection, hoping to exploit vulnerabilities in its implementation or downgrade a secure connection.
• Scope: Web servers running any operating system and web server software that still supports S-HTTP are affected. Specific versions depend on the server software.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking its configuration or using network analysis tools. A quick check involves examining the server’s supported protocols, while thorough assessment requires testing with an S-HTTP client.

• Quick checks: Use `openssl s_client -connect :443` and look for “S-HTTP” in the output.
• Scanning: Nessus plugin ID 16859 may identify S-HTTP support, but results should be verified manually.
• Logs and evidence: Web server access logs might show attempts to connect using S-HTTP, though this is unlikely without active probing.

openssl s_client -connect example.com:443

4. Solution / Remediation Steps

The best way to fix this issue is to disable support for S-HTTP and ensure all traffic uses HTTPS. This improves security by removing a rarely used, potentially vulnerable protocol.

4.1 Preparation

• Ensure you have access to modify the web server’s configuration files. A roll back plan is to restore the original configuration file.
• A change window may be needed, depending on your organisation’s policies and impact of downtime.

4.2 Implementation

1. Step 1: Edit your web server’s configuration file (e.g., Apache httpd.conf or Nginx nginx.conf).
2. Step 2: Locate the section configuring SSL/TLS protocols.
3. Step 3: Remove any lines that explicitly enable S-HTTP, or ensure HTTPS is the only enabled protocol.
4. Step 4: Restart your web server to apply the changes.

4.3 Config or Code Example

Before

SSLProtocol all -SSLv2 +SSLv3

After

SSLProtocol TLSv1.2 TLSv1.3 

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue and similar vulnerabilities. Least privilege reduces the impact if a protocol is exploited, while secure defaults ensure that only necessary services are enabled. A regular patch cadence keeps your systems up-to-date with the latest security fixes.

• Practice 1: Apply least privilege to web server processes to limit potential damage from exploitation.
• Practice 2: Use secure defaults when configuring web servers, disabling unnecessary protocols like S-HTTP.

4.5 Automation (Optional)

If using configuration management tools, you can automate the removal of S-HTTP support across multiple servers.

# Example Ansible task to remove SSLProtocol directive containing S-HTTP
- name: Remove S-HTTP from SSLProtocol directive
  lineinfile:
    path: /etc/apache2/mods-enabled/ssl.conf
    regexp: '^SSLProtocol.*S-HTTP'
    state: absent

5. Verification / Validation

Confirm the fix by checking that S-HTTP is no longer supported and HTTPS connections work correctly. A negative test involves attempting an S-HTTP connection, which should fail.

• Post-fix check: Run `openssl s_client -connect :443` again; “S-HTTP” should not appear in the output.
• Re-test: Re-run the Nessus scan (ID 16859) and confirm it no longer reports S-HTTP support.
• Smoke test: Verify that users can still access your website using HTTPS.
• Monitoring: Check web server logs for any errors related to SSL/TLS configuration changes.

openssl s_client -connect example.com:443

6. Preventive Measures and Monitoring

Update your security baselines to include disabling S-HTTP as a standard practice. Incorporate checks in your CI/CD pipelines to prevent the reintroduction of this vulnerability during deployments, for example through SAST or IaC scanning. Regular patch reviews ensure timely updates.

• Baselines: Update your security baseline to require disabling S-HTTP on all web servers.
• Pipelines: Add a check in your CI/CD pipeline to scan configuration files for the presence of S-HTTP settings.
• Asset and patch process: Review server configurations regularly (e.g., quarterly) to ensure compliance with security baselines.

7. Risks, Side Effects, and Roll Back

Disabling S-HTTP should not cause any service disruption if it wasn’t actively used. However, always test changes thoroughly. If issues occur, restore the original web server configuration file.

• Roll back: Restore the previous version of your web server’s configuration file and restart the service.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for specific guidance on disabling S-HTTP.
• NVD or CVE entry: No specific CVE is associated with this detection, but research CWE-301 for related information.
• Product or platform documentation relevant to the fix: https://tools.ietf.org/html/rfc2660 provides details on S-HTTP.