Dns Rebinding in Actix with Mutual Tls

DNS rebinding is a network-based attack where a malicious actor manipulates DNS responses to redirect a client from an initial IP address to a different, often internal, address. In an Actix web service that enforces Mutual TLS (mTLS), the client presents a certificate during the TLS handshake and the server validates it. If the server uses the client certificate subject or serial number to decide whether a request is trusted, an attacker can bypass this trust by first completing mTLS with a benign external IP, then rebinding the DNS name to an internal host mid-session. Because mTLS is verified only at connection setup, the established session may still be accepted for subsequent requests to the rebound internal address, allowing the attacker to make the server call internal services on behalf of the authenticated client.

Actix does not inherently prevent DNS changes after the TLS handshake; the framework processes requests within an established connection where the peer certificate is already validated. An mTLS-enabled Actix endpoint that uses client identity for authorization—such as extracting a principal from the certificate and using it in route guards or data access logic—can be abused if the attacker rebinds DNS to reach internal endpoints that the client certificate is mistakenly allowed to access. For example, an endpoint that checks only certificate validity but then forwards requests internally (service-to-service calls, admin interfaces, or local management APIs) may expose sensitive operations to the external attacker once DNS points inward.

Consider a scenario where an mTLS-protected Actix API authorizes access based on certificate fields (e.g., organizational unit). An attacker with a valid client certificate connects to api.example.com, which initially resolves to a public IP. After mTLS succeeds, the attacker uses a DNS rebinding payload that causes subsequent HTTP requests to resolve to 127.0.0.1 or an internal Kubernetes service IP. The server continues to trust the client certificate and may route requests to internal endpoints that were never intended for external consumption, leading to unauthorized actions or information disclosure. This highlights the need to treat mTLS as transport assurance only and to enforce additional network-level and request-level checks in Actix rather than relying on IP-based assumptions derived from DNS.

To mitigate DNS rebinding in an Actix service using Mutual TLS, do not rely on client certificate validation alone for authorization or network boundary enforcement. Combine mTLS with explicit hostname verification, strict request validation, and network segmentation. Below are concrete, realistic examples of how to implement mTLS in Actix and augment it with protections relevant to DNS rebinding.

First, configure an Actix server with mTLS using native Rust TLS facilities. The following snippet demonstrates loading server certificates and requiring client authentication:

use actix_web::{web, App, HttpServer, Responder};
use actix_web::dev::Server;
use std::sync::Arc;
use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};

fn create_ssl_config() -> std::io::Result {
    let mut builder = SslAcceptor::mozilla_intermediate(SslMethod::tls())?;
    builder.set_private_key_file("key.pem", SslFiletype::PEM)?;
    builder.set_certificate_chain_file("cert.pem")?;
    builder.set_client_ca_file("ca.pem")?;
    builder.set_verify(openssl::ssl::SslVerifyMode::PEER | openssl::ssl::SslVerifyMode::FAIL_IF_NO_PEER_CERT, 
        verify_callback);
    Ok(builder.build())
}

fn verify_callback(verified: bool, cert: &openssl::x509::X509) -> bool {
    // Perform additional checks here: certificate extensions, SAN, or custom fields
    verified && !is_private_address(cert)
}

fn is_private_address(cert: &openssl::x509::X509) -> bool {
    // Example stub: inspect SAN/IP extensions to reject certs mentioning private ranges
    // Real implementation should parse SAN/IP entries and compare against allowed ranges
    false
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let ssl = create_ssl_config().expect("Failed to create SSL acceptor");
    HttpServer::new(|| {
        App::new()
            .wrap(mtls_logger()) // hypothetical wrapper for logging cert subject
            .route("/api/act", web::get().to(act_handler))
    })
    .bind_openssl("0.0.0.0:8443", ssl)?
    .run()
    .await
}

async fn act_handler() -> impl Responder {
    // Handle request with mTLS context
    "OK"
}

Second, enforce hostname binding by validating the TLS server name indication (SNI) and the certificate’s subject alternative names (SAN) against an allowlist. DNS rebinding often relies on a single name that later resolves differently; pinning the expected hostname prevents the server from accepting connections intended for internal names.

Third, avoid using client certificate-derived identifiers (such as CN or OU) for routing to internal services. Instead, treat the certificate as proof of possession and rely on an independent authorization layer that inspects the request path, headers, and context. In Actix, this can be implemented as a guard that checks request targets and rejects attempts to reach internal paths when the origin is external:

use actix_web::{dev::ServiceRequest, Error, Either, guard, web};
use actix_web::http::header::HOST;

async fn authorize_request(req: ServiceRequest) -> Result, Error> {
    let host = req.headers().get(HOST)
        .and_toh_str()
        .unwrap_or("");
    // Reject requests that appear to target internal destinations
    if host.ends_with(".internal") || req.path().starts_with("/internal/") {
        return Err(actix_web::error::ErrorForbidden("access denied"));
    }
    Ok(Either::Left(req))
}

// Apply in App::new().wrap_fn(|req, srv| authorize_request(req).and_then(|e| srv.call(e)))

Finally, place mTLS endpoints behind network controls that limit which source addresses can reach internal services, and regularly rotate certificates to reduce the impact of compromised credentials. These steps reduce the attack surface available to DNS rebinding even when mTLS is in use.