Bleichenbacher Attack in Actix with Mutual Tls

A Bleichenbacher attack targets the way an implementation handles padding errors during RSA decryption. In an Actix web service that uses Mutual TLS (mTLS) for client authentication, the presence of mTLS does not automatically prevent this class of attack; it changes the threat surface. mTLS ensures that only clients possessing a valid certificate can establish a TLS connection, but once the connection is established, application-layer processing remains the same. If the Actix service performs RSA decryption of client-supplied data (for example, decrypting a JWT or an encrypted payload) and uses a padding oracle, an authenticated client can iteratively submit ciphertexts and observe distinct responses to learn the plaintext. The mTLS layer provides identity and transport integrity, but it does not hide error behavior from the authenticated client.

In practice, this means an attacker that has obtained a valid client certificate (through compromise, misissuance, or a rogue CA) can interact with the Actix endpoint and perform a padding oracle attack such as the classic Bleichenbacher adaptive chosen-ciphertext attack. The attacker sends modified ciphertexts and uses timing differences or explicit error messages (e.g., bad padding vs. bad signature) to gradually recover the plaintext. Common vulnerable patterns in Actix applications include custom decryption routines that return different HTTP status codes or response bodies for padding failures, and integrations with TLS-terminated frontends that pass client certificates into the application for additional checks.

Key contributing factors specific to the Actix + mTLS combination include:

• Differentiated error handling in application code that distinguishes between TLS-level failures and application decryption failures, enabling oracle behavior.
• Use of RSAES-PKCS1-v1_5 padding in application-layer decryption without constant-time verification or blinding, which is still seen in legacy integrations.
• Assumption that mTLS alone secures the channel, leading to relaxed scrutiny of decrypted content and error messages returned to authenticated peers.

Even with mTLS in place, if the Actix application does not uniformly handle decryption errors and does not implement countermeasures such as blinding or strict error suppression, the Bleichenbacher attack remains feasible at the application layer despite the mutual authentication guarantees of TLS.

Remediation focuses on ensuring that decryption errors do not leak information and that mTLS is treated as a transport safeguard rather than a complete defense against application-layer attacks. Below are concrete Actix examples that demonstrate secure handling.

1. Constant-time decryption verification and uniform error responses

use actix_web::{web, HttpResponse, Result};
use rsa::{RsaPrivateKey, PaddingScheme};
use subtle::ConstantTimeEq;

async fn secure_decrypt(
    payload: web::Json>,
    key: web::Data,
) -> Result {
    let padding = PaddingScheme::new_pkcs1v15_encrypt();
    // Perform decryption; catch any low-level errors and map to a generic response.
    let decrypted = match key.decrypt(padding, &payload) {
        Ok(data) => data,
        Err(_) => {
            // Always return the same generic error and status to avoid leaking padding failures.
            return Ok(HttpResponse::BadRequest().json(serde_json::json!({
                "error": "invalid_request"
            })));
        }
    };
    // Further processing…
    Ok(HttpResponse::Ok().body("success"))
}

The example uses a generic error path for all decryption failures, preventing an attacker from distinguishing padding errors from other issues. The subtle crate can be used for constant-time comparisons when validating signatures or hashes derived from the decrypted plaintext.

2. Enforce authenticated encryption instead of raw RSA

use actix_web::web;
use aes_gcm::{Aes256Gcm, KeyInit, aead::{Aead, OsRng}};
use rsa::{RsaPrivateKey, PaddingScheme};

async fn hybrid_decrypt(
    wrapper: web::Json>,
    payload: web::Json>,
    key: web::Data,
) -> Result {
    // Step 1: RSA-OAEP unwraps a symmetric key
    let padding = PaddingScheme::new_oaep::();
    let sym_key = key.decrypt(padding, &wrapper)?;
    // Step 2: Use the symmetric key with an AEAD scheme for the actual data
    let cipher = Aes256Gcm::new(&sym_key.into());
    let nonce = aes_gcm::Nonce::from_slice(&payload[..12]);
    let data = cipher.decrypt(nonce, payload[12..].as_ref())
        .map_err(|_| actix_web::error::ErrorBadRequest("invalid"))?;
    Ok(web::Json(data))
}

By using RSA only to encrypt a symmetric key and relying on AEAD for bulk data, you reduce the exposure of raw RSA operations and avoid padding oracle risks associated with PKCS#1 v1.5 in application-layer decryption.

3. Middleware to normalize errors and suppress verbose messages

use actix_web::{dev::ServiceRequest, dev::ServiceResponse, Error, middleware::Next};
use actix_web::body::BoxBody;

pub async fn suppress_decryption_errors(
    req: ServiceRequest,
    next: Next,
) -> Result, Error> {
    let res = next.call(req).await;
    // Map internal errors to a generic response without stack or error-type details.
    res.map(|mut r| {
        if r.status().is_server_error() {
            *r.get_mut() = BoxBody::from("Internal Server Error");
        }
        r
    })
}

Use this middleware to ensure that any unexpected internal errors (including those triggered during decryption or mTLS handshake processing) do not return details that could aid an attacker in building an oracle.

4. mTLS configuration in Actix with explicit client verification

use actix_web::HttpServer;
use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};

fn create_ssl_acceptor() -> SslAcceptor {
    let mut builder = SslAcceptor::mozilla_intermediate(SslMethod::tls()).unwrap();
    builder.set_private_key_file("key.pem", SslFiletype::PEM).unwrap();
    builder.set_certificate_chain_file("cert.pem").unwrap();
    // Require and verify client certificates
    builder.set_verify(openssl::ssl::SslVerifyMode::PEER | openssl::ssl::SslVerifyMode::FAIL_IF_NO_PEER_CERT);
    builder.set_ca_file("ca.pem").unwrap();
    builder.build()
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let ssl = create_ssl_acceptor();
    HttpServer::new(move || {
        actix_web::App::new()
            .wrap(actix_web_openssl::SslWrap::new(ssl.clone()))
            .route("/secure", actix_web::web::post().to(secure_decrypt))
    })
    .bind_openssl("127.0.0.1:8443", ssl)?
    .run()
    .await
}

This server configuration enforces mTLS at the TLS layer and ensures client certificates are validated before requests reach Actix handlers. Combined with constant-time application-layer decryption and generic error responses, it mitigates Bleichenbacher-style padding oracle attacks even when authenticated clients are involved.