Http Request Smuggling in Chi with Mutual Tls

HTTP request smuggling occurs when an attacker can send a request that is interpreted differently by a frontend (e.g., a load balancer or reverse proxy terminating Mutual TLS) and a backend application (e.g., a Chi server). In a Mutual TLS setup, the frontend validates client certificates before forwarding traffic to the backend. If the frontend and backend have different HTTP parsing behaviors, smuggling becomes possible even when Mutual TLS is enforced.

Chi is a minimal HTTP router and middleware framework for Go. When you place Chi behind a frontend that terminates Mutual TLS, the frontend typically parses the request first (validating the client certificate and possibly normalizing headers), then forwards the request to Chi. If the frontend buffers or modifies the request body or headers differently than Chi does, an attacker can craft a request that appears valid to the frontend but is interpreted differently by Chi. Common smuggling techniques like CL.TE or TE.CL can be exercised by sending a request with both Content-Length and Transfer-Encoding headers, or with chunked encoding, to exploit parsing discrepancies.

With Mutual TLS, the TLS layer is terminated at the frontend, so the encrypted payload is decrypted and inspected before forwarding. This inspection can include header manipulation or body buffering, which may introduce differences in how the request is parsed. For example, a frontend might strip or merge headers, or handle the request body differently before passing it to Chi. If Chi reads the body based on Transfer-Encoding while the frontend has already consumed or altered the body, the backend may process an unexpected request path or route, leading to request smuggling. This is especially risky when the frontend performs partial parsing for access control or certificate checks and then forwards the request to Chi, which may apply different routing logic.

An attacker can exploit this by sending a single request that contains both Content-Length and Transfer-Encoding headers. The frontend might process one header and forward the request with the other header still present. Chi, depending on how it is configured and which Go HTTP library settings are used, may honor the remaining header, causing the request to be split or smuggled. Because Mutual TLS ensures the frontend is trusted, developers may assume the request is safe after TLS validation, but parsing differences remain a risk. The smuggling target can be an internal route in Chi that behaves differently based on path or method, allowing the attacker to bypass intended routing, access unauthorized endpoints, or cause request handling errors.

To detect such issues, scanning with a tool that supports OpenAPI/Swagger analysis and runtime testing against the unauthenticated attack surface is valuable. The scanner can probe endpoints with malformed headers, including smuggling indicators, and compare findings against the spec to identify risky parsing configurations. Even in Mutual TLS deployments, the unauthenticated attack surface includes the frontend-to-backward request path, making these checks relevant.

Remediation focuses on ensuring consistent HTTP parsing between the Mutual TLS frontend and the Chi backend, and avoiding reliance on potentially modified headers. Below are concrete code examples for a Chi service that assume the frontend terminates Mutual TLS and forwards requests safely.

First, configure Chi to strictly parse HTTP messages and avoid relying on headers that may be manipulated or normalized by the frontend. Use explicit middleware to validate and normalize the request before routing.

import (
  "net/http"
  "github.com/go-chi/chi/v5"
  "github.com/go-chi/chi/v5/middleware"
)

func main() {
  r := chi.NewRouter()
  // Enforce header normalization and reject requests with both Content-Length and Transfer-Encoding
  r.Use(middleware.RequestID)
  r.Use(middleware.RealIP)
  r.Use(func(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
      // Reject smuggling attempts: if both headers are present, respond with 400
      if r.Header.Get("Content-Length") != "" && r.Header.Get("Transfer-Encoding") != "" {
        http.Error(w, "invalid headers", http.StatusBadRequest)
        return
      }
      next.ServeHTTP(w, r)
    })
  })
  // Define routes safely, using explicit methods and paths
  r.Get("/api/resource", func(w http.ResponseWriter, r *http.Request) {
    // Process request body with strict decoding; do not trust header values implicitly
    // ...
  })
  http.ListenAndServe(":8080", r)
}

Second, ensure the frontend and backend agree on how the request body is consumed. If the frontend buffers the body for inspection (e.g., for certificate-based authorization), it must forward the exact bytes to Chi, or rewind the body if it has been read. In Go, you can replace the request body with an io.NopCloser on a copied buffer to avoid premature reads.

func copyBody(r *http.Request) *http.Request {
  if r.Body == nil {
    return r
  }
  buf, err := io.ReadAll(r.Body)
  if err != nil {
    // handle error appropriately
    return r
  }
  // Replace body with a new Reader so Chi can read it safely
  r.Body = io.NopCloser(bytes.NewBuffer(buf))
  r.ContentLength = int64(len(buf)) // ensure length is consistent
  return r
}

Third, avoid enabling chunked transfer encoding acceptance unless necessary, and configure the Go HTTP server used by Chi to reject ambiguous encodings. You can set `DisableHTTP2` and tune `ReadHeaderTimeout` to reduce the window for smuggling. Also, ensure that any middleware in Chi that modifies headers does not inadvertently re-introduce smuggling vectors.

Finally, validate that the Mutual TLS frontend does not strip or alter headers in a way that creates discrepancies with Chi’s expectations. Document and test the forwarding behavior, and consider running scans that include smuggling probes against the public endpoint to verify that parsing remains consistent across the stack.