Padding Oracle with Mutual Tls

Mutual TLS (mTLS) adds client‑certificate authentication to the standard TLS handshake, but the underlying record‑layer encryption is unchanged. If the server negotiates a CBC‑mode cipher suite (e.g., TLS_RSA_WITH_AES_128_CBC_SHA) and its implementation distinguishes between "bad record MAC" and "decryption failed" alerts, an attacker can exploit a padding oracle.

During the handshake, after the ServerHello, the client encrypts the ClientKeyExchange, CertificateVerify (if client cert is sent), and Finished messages using the agreed‑upon cipher. An active attacker who can inject modified ciphertexts and observe whether the server returns a decrypt_error alert (padding invalid) versus a bad_record_mac alert (MAC failure) can iteratively decrypt bytes of the encrypted handshake.

Because mTLS requires the client to present a valid certificate, the attacker must be able to present a client certificate that the server trusts, or they must act as a man‑in‑the‑middle that terminates TLS on the server side and initiates a new TLS session to the client. In many deployments (e.g., APIs behind a load balancer that does mTLS termination), the attacker only needs to control the network path to the termination point and can send crafted ClientKeyExchange fragments while presenting a valid client cert (or using a stolen/reused cert). The server’s differing alert types give the oracle needed to recover the pre‑master secret, which then reveals the session keys and allows decryption of subsequent application data.

Real‑world analogues include the POODLE attack (CVE‑2014-3566) against SSL 3.0 CBC mode and the Lucky Thirteen attack (CVE‑2013-0169) against TLS CBC implementations. When mTLS is used, the same flaws apply because the record layer does not differentiate between client‑authenticated and unauthenticated sessions.

Detecting a padding oracle in an mTLS‑protected API requires probing the TLS layer, not the application HTTP layer. middleBrick’s unauthenticated black‑box scan includes an Encryption check that:

• Enumerates the TLS versions and cipher suites the server offers.
• Checks whether any CBC‑mode ciphers are enabled (e.g., TLS_RSA_WITH_*_CBC_*).
• Attempts to trigger distinct TLS alerts by sending malformed CBC‑record padding and observes whether the server returns decrypt_error (alert 21) versus bad_record_mac (alert 20).
• Measures timing or response differences that could leak padding validity.

If the server is configured to require a client certificate, middleBrick still performs the TLS handshake because it does not need to present a valid cert to discover the cipher suite and alert behavior; the server will abort the handshake with a handshake_failure alert, but the preceding ServerHello and cipher suite negotiation are still visible. middleBrick therefore reports the presence of CBC ciphers and any observable padding‑oracle behavior under the Encryption category, with a severity rating based on whether distinct alerts are detectable.

Example finding (JSON excerpt from middleBrick CLI):

{
  "check": "Encryption",
  "finding": "CBC mode cipher suite enabled with distinguishable padding oracle alerts",
  "severity": "high",
  "remediation": "Disable CBC ciphers; prefer TLS 1.2+ with GCM or ChaCha20-Poly1305 suites."
}

This output lets developers see that the mTLS endpoint is potentially vulnerable to a padding‑oracle attack even though client‑cert authentication is in place.

The most reliable fix is to eliminate CBC‑mode cipher suites from the server’s TLS configuration and to use TLS versions that provide authenticated encryption (AEAD) ciphers only. Because mTLS does not change the cryptographic primitives used for record protection, the same hardening steps apply as for ordinary TLS.

Server‑side configuration examples

NGINX (terminating mTLS)

# /etc/nginx/conf.d/mtls.conf
server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;

    # TLS 1.2+ only, AEAD ciphers
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://backend;
    }
}

Java (using JSSE)

SSLContext ctx = SSLContext.getInstance("TLSv1.2");
ctx.init(keyManagers, trustManagers, new SecureRandom());
SSLEngine engine = ctx.createSSLEngine();
engine.setEnabledProtocols(new String[] {"TLSv1.2", "TLSv1.3"});
engine.setEnabledCipherSuites(new String[] {
    "TLS_AES_256_GCM_SHA384",
    "TLS_CHACHA20_POLY1305_SHA256",
    "TLS_AES_128_GCM_SHA256"
});
// No CBC suites are enabled, removing padding‑oracle surface.

Node.js (tls module)

const tls = require('tls');
const options = {
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt'),
  ca: fs.readFileSync('ca.crt'),
  requestCert: true,
  rejectUnauthorized: true,
  secureProtocol: 'TLSv1_2_method',
  ciphers: 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256'
};
const server = tls.createSecureContext(options);
// Server now only negotiates AEAD ciphers; CBC‑mode padding oracle is impossible.

Additionally, ensure that the TLS library you are using returns identical alert types or timing for any decryption failure. Modern OpenSSL (≥1.0.1), BoringSSL, and Java JSSE already constant‑time handle padding errors, but verifying the configuration (as above) guarantees that no CBC ciphers remain enabled.

After applying these changes, re‑run middleBrick scan; the Encryption check should report "No CBC mode cipher suites detected" and the padding‑oracle finding will disappear.