Request Smuggling in Aspnet with Mutual Tls

Request smuggling occurs when an intermediary (such as a load balancer or reverse proxy) and the origin server interpret the boundaries of an HTTP request differently. In ASP.NET applications that terminate Mutual TLS (mTLS), the presence of client certificates at the edge can change how requests are buffered and forwarded, which may amplify smuggling risks. With mTLS, the server authenticates the client using a client certificate during the TLS handshake before the HTTP request is processed. This handshake completion can make the edge appear as a trusted client to the origin, causing the origin to process requests that the edge may have modified or split.

When mTLS is enforced, some deployments place the mTLS termination at the load balancer and forward the request to the backend over a separate TLS connection. If the frontend uses one transfer encoding (e.g., chunked) and the backend expects Content-Length, or vice versa, the boundary between the two can be misaligned. ASP.NET’s default parsers may normalize or buffer the request differently depending on whether a client certificate was validated, potentially allowing a malicious request to be interpreted differently by the edge and the application. For example, a request with an invalid Transfer-Encoding and Content-Length combination might pass the edge if mTLS validation succeeds, but the ASP.NET runtime may parse the message in a way that allows request body splitting or request header manipulation to reach the application layer.

In practice, an attacker can craft a request that includes both Transfer-Encoding: chunked and a Content-Length header while leveraging a valid client certificate to satisfy mTLS requirements. If the edge terminates mTLS and forwards the request with altered framing, the origin ASP.NET application might process the request with an incorrect body boundary. This can lead to request smuggling outcomes such as request splitting, where an injected request is served to another user, or response splitting, where injected content affects downstream responses. Because mTLS changes the trust boundary and may suppress certain parsing failures at the edge, the application can end up processing a request that bypasses intended routing or isolation controls.

To reduce smuggling risk in ASP.NET applications with Mutual TLS, align parsing behavior between edge and origin, avoid accepting ambiguous framing, and harden how the framework interprets headers. Ensure consistent handling of Transfer-Encoding and Content-Length across the path, and prefer rejecting requests that contain both rather than attempting to normalize them.

Example 1: Enforce consistent HTTP protocol parsing in ASP.NET Core

Configure Kestrel to strictly reject requests that contain both Transfer-Encoding and Content-Length to prevent ambiguous framing that can be exploited in smuggling scenarios, even when mTLS is used.

// Program.cs
var builder = WebApplication.CreateBuilder(args);

// Enforce strict HTTP parsing
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxRequestBodySize = 10_000_000; // 10 MB
});

// Require explicit limits and reject ambiguous framing
builder.Services.Configure<HttpParserOptions>(options =>
{
    options.AllowSynchronousIO = false;
});

var app = builder.Build();

// Reject requests that contain both headers
app.Use(async (context, next) =>
{
    var request = context.Request;
    bool hasTE = request.Headers.ContainsKey("Transfer-Encoding");
    bool hasCL = request.Headers.ContainsKey("Content-Length");

    if (hasTE && hasCL)
    {
        context.Response.StatusCode = 400;
        await context.Response.WriteAsync("Ambiguous framing: Transfer-Encoding and Content-Length cannot both be present.");
        return;
    }

    await next(context);
});

app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

app.Run();

Example 2: mTLS configuration with explicit client certificate validation

Ensure client certificates are validated early and that forwarded requests preserve the original framing decisions. This example shows how to require and validate client certificates in ASP.NET Core and avoid forwarding ambiguous headers.

// Program.cs with mTLS
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureHttpsDefaults(httpsOptions =>
    {
        httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
        httpsOptions.AllowAnyClientCertificate(); // Replace with custom validation in production
        // Optionally use custom validation:
        // httpsOptions.ClientCertificateValidation = (cert, chain, errors) => MyValidateClientCert(cert, chain, errors);
    });
});

// Custom validation example (simplified)
bool MyValidateClientCert(X509Certificate? cert, X509Chain? chain, SslPolicyErrors errors)
{
    if (cert == null) return false;
    // Example policy: thumbprint check or chain validation
    return errors == SslPolicyErrors.None;
}

// Middleware to strip or reject ambiguous framing before routing
builder.Services.AddTransient<IFrameValidationMiddleware>((sp) => new FrameValidationMiddleware());

var app = builder.Build();

app.Use(async (context, next) =>
{
    var request = context.Request;
    bool hasTE = request.Headers.ContainsKey("Transfer-Encoding");
    bool hasCL = request.Headers.ContainsKey("Content-Length");

    if (hasTE && hasCL)
    {
        context.Response.StatusCode = 400;
        await context.Response.WriteAsync("Ambiguous framing: Transfer-Encoding and Content-Length cannot both be present.");
        return;
    }

    await next(context);
});

// Use mTLS and routing
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();

Additional practices

• Ensure edge and origin use the same HTTP parser settings and reject ambiguous Transfer-Encoding/Content-Length combinations.
• Do not automatically forward or normalize framing headers after mTLS termination; explicitly drop or reject requests that could be smuggled.
• Validate client certificates before using them to make trust decisions about request integrity.