Cleartext HTTP/2

What Cleartext HTTP/2 Means

Cleartext HTTP/2, often called h2c, is HTTP/2 carried without TLS encryption. That makes the protocol visible in transit, which is unusual on public services and immediately changes the trust assumptions around confidentiality, integrity, and endpoint authenticity.

In practice, h2c is most often seen where HTTP/2 is used on trusted internal networks, in controlled test environments, or behind gateways that terminate encryption elsewhere. On the open internet, it is more of a red flag than a normal deployment choice.

Why Cleartext HTTP/2 Is Operationally Unusual

Most browsers and internet-facing clients negotiate HTTP/2 over TLS, so cleartext HTTP/2 usually means the service is outside the normal secure browser path. That matters because many security controls, including interception resistance, certificate validation, and encrypted transport assumptions, are bypassed or absent.

Its presence can indicate a deliberate design choice, but it can also reveal an accidental downgrade path or an internal-only service exposed beyond its intended boundary. When that happens, the issue is not just transport format, it is a mismatch between how the service is configured and how it is reachable.

Security Implications of Using h2c

Without TLS, traffic can be read or altered by any intermediary with network access. That creates exposure for credentials, session material, API requests, and responses if the application carries sensitive data over the connection.

Cleartext HTTP/2 also weakens confidence in server identity because the client is not relying on certificate-based authentication. If the deployment expects authenticated peers, encrypted transport is part of the trust boundary, not an optional enhancement.

How Teams Validate and Contain Exposure

Teams should confirm whether h2c is intentionally used, where it is allowed, and whether any exposed listener is reachable from untrusted networks. The most reliable checks are an asset inventory, configuration review, packet inspection, and comparison with vendor deployment guidance for the exact service.

If cleartext HTTP/2 is only supposed to exist behind a reverse proxy or inside a private segment, then exposure should be treated as a boundary failure. A conservative operational stance is to prefer encrypted transport everywhere the service can be reached by users, clients, or other systems outside a tightly controlled trust zone.

Risk and Threat Considerations

Cleartext HTTP/2 creates a straightforward interception and tampering risk when it crosses networks that are not fully trusted. It can also expose a hidden downgrade path, where a service intended to negotiate secure HTTP/2 silently falls back to an unencrypted mode.

Failure mechanism: A misconfigured listener, proxy, or service endpoint accepts h2c where encrypted HTTP/2 was expected, allowing traffic disclosure, request manipulation, or credential capture on the path.

Impact: Attackers or intermediaries can observe or modify application traffic, which may compromise secrets, sessions, API calls, and downstream trust decisions made by the application or adjacent controls.

Practitioner Guidance

Why practitioners should care: Treat h2c as a deployment decision that must be explicitly justified, not as a benign protocol variant. If the service is internet-facing or carries sensitive data, cleartext transport usually signals a control gap that deserves review.

What to watch for: Look for unexpected cleartext listeners, reverse-proxy rules that permit downgrade, and services that behave differently in internal versus external environments. If the service is meant to support authentication, API traffic, or user sessions, verify that transport protection matches that expectation.

For protocol-specific transport and authorization guidance, the Model Context Protocol: Authorization specification shows how modern HTTP transports are expected to preserve strong access boundaries, while the NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 provide the broader control lens for secure communications, configuration, and monitoring.

Related resources from NHI Mgmt Group

• How do you stop OpenAPI definitions allowing API keys or credentials over cleartext HTTP?
• How should security teams decide between WinRM over HTTP and HTTPS?
• What do teams get wrong about WinRM over HTTP security?
• How should teams respond when Apache HTTP Server has a remote code execution CVE?