Padding Oracle in Axum with Mutual Tls

A padding oracle attack occurs when an application reveals information about the validity of a padding block during decryption. In Axum, this typically arises when server-side decryption logic returns distinct errors for invalid padding versus invalid authentication tags. When mutual TLS is in use, the transport is authenticated and encrypted, but developers may assume the channel itself protects against application-layer tampering. This assumption can lead to insufficient error handling around decrypted payloads. For example, if an endpoint accepts an encrypted JWT or encrypted request body over an mTLS connection and uses AES-CBC without proper integrity verification before decryption, an attacker who can position themselves as a valid client (presenting a mTLS certificate) may send manipulated ciphertexts. The service processes these within the same runtime context as legitimate traffic. If the decryption routine throws different exceptions or HTTP status codes for padding errors versus other failures, an attacker can iteratively adapt ciphertexts and observe responses, gradually recovering plaintext without needing to break the cipher.

Mutual TLS ensures that only authenticated clients can connect, but it does not prevent an authenticated client from sending maliciously crafted ciphertexts to the server. In Axum, if the application deserializes and immediately decrypts incoming payloads before validating integrity, the server becomes a padding oracle for that authenticated session. The presence of mTLS reduces the attack surface by limiting who can connect, but it does not eliminate the need for authenticated decryption. An attacker with a valid certificate can still probe the error behavior. Additionally, if Axum services are behind a load balancer or reverse proxy that terminates mTLS, the backend may see plain HTTP and inadvertently expose decryption errors in HTTP status codes or response bodies, making the oracle observable externally. This combination—mTLS for transport identity and a weak decryption pattern—creates a scenario where confidentiality can be undermined despite strong transport security.

Real-world relevance includes scenarios where Axum services process sensitive data such as tokens or personal information. For instance, an endpoint that decrypts a ciphertext using AES-CBC with an integrity check performed after decryption can be vulnerable if padding errors are distinguishable. Consider a handler that returns 400 for padding errors and 401 for authentication failures. An attacker can craft ciphertexts and use timing or status-code differences to infer padding validity, even when mTLS is enforced. This aligns with OWASP API Security Top 10:2023 — API1:2023 Broken Object Level Authorization often intersects with weak cryptography practices. Historical incidents in other frameworks show that padding oracles can lead to plaintext recovery without needing to compromise the private key, provided the attacker can submit chosen ciphertexts and observe differentiated responses.

To mitigate padding oracle risks in Axum while using mutual TLS, ensure that decryption either uses an authenticated encryption mode or performs integrity verification before any padding-sensitive operations. Avoid returning different error codes or timing differences based on padding validity. Instead, use constant-time validation and return a uniform error response for all decryption failures. Below are concrete Axum examples that demonstrate secure patterns.

Example 1: AES-GCM authenticated decryption with mTLS-aware handler

use axum::{routing::post, Router, extract::State};
use std::sync::Arc;
use aes_gcm::{Aes256Gcm, Key, Nonce, aead::{Aead, KeyInit, generic_array::GenericArray}};
use hyper::StatusCode;

struct AppState {
    cipher: Aes256Gcm,
}

async fn decrypt_handler(
    State(state): State>,
    payload: String,
) -> Result {
    // Expect base64-encoded nonce|ciphertext|tag
    let data = base64::decode(payload).map_err(|_| (StatusCode::BAD_REQUEST, "invalid input".into()))?;
    if data.len() != 40 { // 12-byte nonce + 16-byte tag + variable ciphertext
        return Err((StatusCode::BAD_REQUEST, "invalid input".into()));
    }
    let (nonce_bytes, ct_tag) = data.split_at(12);
    let nonce = Nonce::from_slice(nonce_bytes);
    let key = Key::from_slice(b"an example very very secret key."); // Use secure key management
    let cipher = Aes256Gcm::new(key);
    match cipher.decrypt(nonce, ct_tag.as_ref()) {
        Ok(plaintext) => String::from_utf8(plaintext).map_err(|_| (StatusCode::BAD_REQUEST, "invalid utf8".into())),
        Err(_) => Err((StatusCode::UNAUTHORIZED, "decryption failed".into())), // Uniform error
    }
}

fn app() -> Router> {
    Router::new()
        .route("/decrypt", post(decrypt_handler))
        .with_state(Arc::new(AppState { cipher: Aes256Gcm::new(Key::from_slice(b"an example very very secret key.")) }))
}

Example 2: Axum middleware to enforce mTLS and constant-time failure responses

use axum::{middleware::Next, extract::connect_info::ConnectInfo, http::Request, response::Response, Extension};
use std::net::SocketAddr;
use openssl::ssl::{SslConnector, SslVerifyMode};

// Middleware that checks client certificate presence
pub async fn mtls_aware_middleware(
    request: Request,
    next: Next,
) -> Result {
    // In practice, inspect TLS state via extensions provided by your server framework.
    // Axum does not directly expose peer certs; this is handled upstream.
    // Assume a flag Extension(verified) set by a higher layer.
    let verified = request.extensions().get::().copied().unwrap_or(false);
    if !verified {
        return Err((StatusCode::FORBIDDEN, "mTLS required".into()));
    }
    Ok(next.run(request).await)
}

// Integration example
fn app_with_mtls() -> Router {
    Router::new()
        .route("/secure", post(|| async { "ok" }))
        .layer(axum::middleware::from_fn(mtls_aware_middleware))
}