Timing Attack in Actix with Mutual Tls

A timing attack in Actix with Mutual TLS (mTLS) arises when the server’s behavior depends on sensitive data, such as a token or password, and the elapsed response time varies measurably based on that data. Even when transport-layer encryption and client authentication are provided by mTLS, application-level logic can still leak information through observable latency differences. For example, consider an Actix web service that performs per-request client certificate validation plus an additional application secret check. If the service compares the request’s secret using a naive string comparison that short-circuits on the first mismatching byte, an attacker who can influence the request path (for instance by selecting which resource to access or by probing different endpoints) can measure response times and infer how many initial bytes of the secret match. The presence of mTLS ensures the client is authenticated with a certificate, but it does not prevent the application from introducing a data-dependent branching pattern on the secret comparison. This combination means an attacker with a valid mTLS certificate (obtained perhaps via social engineering, compromise, or a stolen device) can iteratively learn the secret byte by byte. In a typical OWASP API Top 10 scenario, this maps to Broken Object Level Authorization (BOLA) and Sensitive Data Exposure, where timing differences disclose information that should remain confidential regardless of transport security.

Real-world attack patterns include probing endpoints with slightly different secrets or tokens and using high-resolution timestamps to detect small variations in response time. For instance, an attacker might send authentication requests with incremental prefixes and observe whether a 401 is returned slightly faster for closer matches. Although mTLS binds the client identity to a certificate, it does not mitigate application-side branching or caching behavior that affects timing. The risk is especially relevant when Actix handlers perform operations like hash verification, database key lookups, or conditional logic based on secrets. Without constant-time comparison and uniform processing paths, the unauthenticated attack surface includes timing side channels even when mTLS is enforced. This aligns with findings from security scans that highlight Authentication and Data Exposure checks, where response-time deviations can be surfaced as actionable findings with severity guidance to remediate via constant-time algorithms and framework-level best practices.

To mitigate timing-related leaks in Actix with mTLS, ensure all secret comparisons are performed in constant time and that handler logic does not branch on sensitive values. Use cryptographic libraries that provide constant-time comparison functions, and structure your code so that execution paths and response times are independent of secret data. Below are concrete, syntactically correct examples demonstrating how to implement secure request handling with mTLS in Actix.

// Cargo.toml dependencies
// actix-web = "4"
// actix-rt = "2"
// rustls = "0.21"
// tokio = { version = "1", features = ["full"] }
// subtle = "2" // for constant-time comparison

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use rustls::{Certificate, ServerConfig};
use std::sync::Arc;
use subtle::ConstantTimeEq;

async fn handler(req_body: String, known_secret: web::Data) -> impl Responder {
    // Constant-time comparison to avoid timing leakage
    let input = req_body.as_bytes();
    let secret = known_secret.as_bytes();

    // Ensure lengths match before comparison to avoid length-based leaks
    let equal = if input.len() == secret.len() {
        input.ct_eq(secret).into()
    } else {
        false.ct_eq(&true) // always false, but length-agnostic timing
    };

    if equal {
        HttpResponse::Ok().body("Authenticated")
    } else {
        HttpResponse::Unauthorized().body("Invalid credentials")
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Load server certificate and private key
    let cert = vec![Certificate(std::fs::read("server-cert.pem").expect("cannot read cert"))];
    let mut cfg = ServerConfig::builder()
        .with_safe_defaults()
        .with_no_client_auth() // we will require client auth via mTLS
        .with_single_cert(cert, rustls::PrivateKey(std::fs::read("server-key.pem").expect("cannot read key")))
        .expect("invalid server certificate or key");

    // Require client authentication
    cfg.client_auth_root_subjects = vec![rustls::DistinguishedNames::new()]; // populate with trusted CA DNs as needed
    // Example: let mut store = rustls::RootCertStore::empty();
    // store.add(&rustls::Certificate(std::fs::read("ca.pem").unwrap())).unwrap();
    // cfg.client_auth_root_subjects = vec![store.subjects()];

    // Start Actix server with mTLS
    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new("my_constant_secret_12345".to_string()))
            .route("/check", web::post().to(handler))
    })
    .bind_rustls("127.0.0.1:8443", cfg)?
    .run()
    .await
}

In this example, the handler uses subtle::ConstantTimeEq to compare the request body to a known secret, ensuring the comparison time does not depend on the input. The length check is performed in a way that avoids branching on secret-dependent conditions. Additionally, the server is configured to require mTLS via ServerConfig, ensuring client certificates are validated at the TLS layer. For production, populate the trusted CA subjects appropriately and rotate secrets outside of code. MiddleBrick scans can surface timing-related findings under Authentication and Data Exposure, and its remediation guidance often recommends such constant-time patterns and mTLS hardening.