Bleichenbacher Attack in Aspnet with Mutual Tls

A Bleichenbacher attack targets RSA encryption schemes that use PKCS#1 v1.5 padding and rely on an oracle that distinguishes between padding errors and other errors. In an ASP.NET application using Mutual TLS (mTLS) for transport-layer authentication, the presence of mTLS does not prevent this application-layer oracle if the server decrypts ciphertext and responds differently based on padding validity. mTLS ensures the identity of the client and server and protects integrity and confidentiality in transit, but once the traffic reaches the ASP.NET application, the server may still perform RSA decryption (for example, to validate a JWT or an encrypted session token) using a vulnerable implementation that leaks padding errors via HTTP status codes, response times, or error messages.

In this context, Mutual TLS provides strong authentication and helps prevent unauthorized parties from initiating connections, but it does not protect against an authenticated client that sends maliciously crafted ciphertext to the application endpoint. If the ASP.NET service uses RSA decryption with PKCS#1 v1.5 and the API response varies based on whether a padding error occurs (e.g., 400 vs 401, or timing differences), the mTLS-authenticated client can act as an oracle. The attacker iteratively sends adapted ciphertexts and observes subtle differences to gradually recover the plaintext without needing to compromise the TLS layer.

An example scenario: an ASP.NET API uses a client certificate for mTLS and also accepts an encrypted JWT in an Authorization header. The JWT is decrypted using RSA with PKCS#1 v1.5. If decryption errors are distinguishable, the mTLS-verified client can still mount a Bleichenbacher attack by sending modified tokens and observing response codes or timing. This shows that enabling mTLS in ASP.NET is important for access control and identity assurance, but it must be paired with secure cryptographic practices to avoid oracle-based key recovery.

To mitigate Bleichenbacher-style oracles in ASP.NET when using Mutual TLS, ensure RSA decryption does not reveal distinguishable errors. Use constant-time padding checks and avoid returning distinct error codes or timing differences for padding failures. Below are concrete examples demonstrating secure practices.

Example 1: Using RSA with OAEP and constant-time handling in ASP.NET

Use OAEP instead of PKCS#1 v1.5, and ensure exception handling does not leak information through status codes or response content.

using System;
using System.Security.Cryptography;

public class SecureDecryptService
{
    private readonly RSA _rsa;

    public SecureDecryptService(string privateKeyPem)
    {
        _rsa = RSA.Create();
        // Load PEM or use certificate store; example uses ImportFromPem for .NET 5+
        _rsa.ImportFromPem(privateKeyPem.ToCharArray());
    }

    public byte[] Decrypt(byte[] ciphertext)
    {
        try
        {
            // Use OAEP with SHA-256 for better security
            return _rsa.Decrypt(ciphertext, RSAEncryptionPadding.OaepSHA256);
        }
        catch (CryptographicException)
        {
            // Return a generic error; avoid distinct handling for padding vs other errors
            throw new CryptographicException("Decryption failed");
        }
    }
}

Example 2: JWT validation with certificate-bound mTLS and constant-time checks

In an ASP.NET API that requires mTLS and validates an encrypted JWT, ensure decryption errors do not affect HTTP responses.

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.IdentityModel.Tokens.Jwt;
using System.Security.Cryptography;

// In Startup.cs or Program.cs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = "https://api.example.com",
            ValidAudience = "https://client.example.com",
            IssuerSigningKey = new RsaSecurityKey(LoadCertificate().GetRSAPrivateKey()),
            // Require mTLS client certificate
            RequireSignedTokens = true
        };
        options.Events = new JwtBearerEvents
        {
            OnMessageReceived = context =>
            {
                // Extract token from header or mTLS claim as appropriate
                context.Token = ExtractTokenFromRequest(context.Request);
                return Task.CompletedTask;
            }
        };
    });

private static string ExtractTokenFromRequest(HttpRequest request)
{
    // Example: read from Authorization header or mTLS mapping
    if (request.Headers.TryGetValue("Authorization", out var authHeader) &&
        authHeader.ToString().StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase))
    {
        return authHeader.ToString().Substring("Bearer ".Length);
    }
    // Fallback or mTLS-based retrieval can be implemented here
    return null;
}

private static RSA LoadCertificate()
{
    // Load certificate with private key securely; in production use secure stores
    var cert = new System.Security.Cryptography.X509Certificates.X509Certificate2(
        "server.pfx", "password",
        System.Security.Cryptography.X509Certificates.X509KeyStorageFlags.MachineKeySet);
    return cert.GetRSAPrivateKey();
}

Additionally, configure the application to fail closed: if decryption or validation fails, return a consistent 401/403 without revealing whether the failure was due to padding, signature, or token structure. Avoid logging raw exceptions that could aid an oracle, and prefer using libraries that implement constant-time comparisons internally.