How to remediate – Allowed HTTP Versions

1. Introduction

The vulnerability “Allowed HTTP Versions” refers to web servers supporting older versions of the HTTP protocol, specifically HTTP/1.0 and HTTP/1.1 alongside more modern protocols like HTTP/2. This matters because older versions have known security weaknesses and can be exploited for attacks such as request smuggling or man-in-the-middle attacks. Systems commonly affected include web servers (Apache, Nginx, IIS) and any application using HTTP for communication. A likely impact is reduced confidentiality, integrity, and availability of web services.

2. Technical Explanation

The Hypertext Transfer Protocol (HTTP) is the foundation of data communication on the World Wide Web. Older versions like HTTP/1.0 and 1.1 have limitations in handling requests concurrently and are susceptible to attacks that exploit these weaknesses. An attacker could potentially inject malicious content or manipulate requests by exploiting differences in how different servers interpret these older protocols.

• Root cause: The web server is configured to accept connections using HTTP/1.0 and/or HTTP/1.1, despite the availability of more secure alternatives like HTTP/2.
• Exploit mechanism: An attacker could craft a malicious HTTP request that exploits vulnerabilities in the parsing or handling of older protocol versions, potentially leading to request smuggling or other attacks. For example, an attacker might send a request with conflicting Content-Length and Transfer-Encoding headers, confusing the server’s parser.
• Scope: Affected platforms include web servers running Apache, Nginx, IIS, and any applications using HTTP for communication. The vulnerability exists on systems where older HTTP versions are enabled.

3. Detection and Assessment

• Quick checks: Use the following command to list supported HTTP versions: curl -I https://your-target-website and review the “HTTP/…” lines in the output.
• Scanning: Nessus plugin ID 16083 can detect allowed HTTP versions. OpenVAS also has relevant scans, but results should be verified.
• Logs and evidence: Examine web server access logs for requests using HTTP/1.0 or HTTP/1.1. Look for patterns indicating older protocol usage.

curl -I https://your-target-website

4. Solution / Remediation Steps

To fix this issue, disable support for HTTP/1.0 and HTTP/1.1 on your web server and enable only HTTP/2 or HTTP/3 where supported. This will reduce the attack surface and improve security.

4.1 Preparation

• Ensure you have access to the web server’s configuration files. A roll back plan involves restoring the original configuration file.
• Changes may require a short maintenance window. Approval from relevant IT teams may be needed.

4.2 Implementation

1. Step 1: Edit your web server’s main configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
2. Step 2: Locate the section defining supported HTTP protocols.
3. Step 3: Remove or comment out any lines enabling HTTP/1.0 and HTTP/1.1.
4. Step 4: Ensure that HTTP/2 is enabled if your server supports it.
5. Step 5: Save the configuration file.
6. Step 6: Restart the web service to apply the changes.

4.3 Config or Code Example

Before

# Apache example:
Protocols http/1.0 http/1.1 http/2

After

# Apache example:
Protocols http/2 

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact if exploited, and secure defaults ensure a strong starting configuration. Patch cadence ensures timely updates for known vulnerabilities.

• Practice 1: Implement least privilege principles by limiting access to web server configurations.
• Practice 2: Use secure defaults when configuring your web server, disabling unnecessary features like older HTTP versions.

4.5 Automation (Optional)

# Example Ansible task to disable HTTP/1.0 and 1.1 in Nginx:
- name: Disable HTTP/1.0 and 1.1 in Nginx configuration
  lineinfile:
    path: /etc/nginx/nginx.conf
    regexp: 'Protocols http/1.0 http/1.1'
    state: absent

5. Verification / Validation

• Post-fix check: Run curl -I https://your-target-website and confirm that the output shows only “HTTP/2” or higher, without any mention of HTTP/1.0 or HTTP/1.1.
• Re-test: Re-run the earlier detection method (using `curl`) to verify that older protocols are no longer supported.
• Smoke test: Access a key web page or API endpoint to confirm basic functionality is still working as expected.
• Monitoring: Monitor web server logs for any errors related to HTTP protocol negotiation.

curl -I https://your-target-website

6. Preventive Measures and Monitoring

Update security baselines to include disabling older HTTP versions. Implement checks in CI/CD pipelines to prevent the same configuration fault from being deployed again. Maintain a sensible patch or config review cycle that fits your risk profile.

• Baselines: Update your web server security baseline to require disabling HTTP/1.0 and HTTP/1.1.
• Pipelines: Add checks in your CI/CD pipeline to scan for insecure configurations, such as enabled older HTTP versions.
• Asset and patch process: Implement a regular review cycle for web server configurations to ensure compliance with security standards.

7. Risks, Side Effects, and Roll Back

Disabling older HTTP versions may cause compatibility issues with very old clients. If this occurs, you can re-enable the protocols temporarily. The roll back steps involve restoring the original web server configuration file.

• Risk or side effect 1: Compatibility issues with legacy clients that only support HTTP/1.0 or HTTP/1.1. Mitigation: Monitor for errors and re-enable older protocols if necessary, but consider upgrading those clients.
• Roll back: Restore the original web server configuration file from your backup. Restart the web service to apply the changes.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s website for specific guidance on disabling older HTTP versions (e.g., Apache, Nginx, Microsoft IIS).
• NVD or CVE entry: Updated on October 26, 2025