Out Of Bounds Read with Mutual Tls

Mutual TLS (mTLS) adds client‑certificate validation to the standard TLS handshake. While this strengthens authentication, it does not change the underlying TLS record processing where memory‑safety bugs can reside. An out‑of‑bounds (OOB) read in the TLS stack can be triggered by a malformed handshake message, extension, or heartbeat request, allowing an attacker to read adjacent memory from the server process.

One of the most famous OOB read vulnerabilities is Heartbleed (CVE-2014-0160) in OpenSSL’s TLS heartbeat extension. When a server with heartbeat enabled receives a malformed HeartbeatRequest that claims a larger payload than actually sent, OpenSSL copies the claimed length from the request into the response, leaking up to 64 KB of server memory per request. In an mTLS deployment the server’s private key is still required to complete the handshake; leaking that key lets an attacker decrypt or impersonate the service, undermining the mutual authentication guarantee.

Other TLS implementations have shown similar issues in extension parsing. For example, CVE-2022-3602 (a buffer overflow in OpenSSL’s punycode decoding) can be reached during processing of a malicious SNI or certificate extension, leading to OOB read/write conditions. In mTLS, the server validates the client certificate chain; if the certificate contains a malformed extension that triggers the bug, the same memory disclosure can occur.

The vulnerable code path typically looks like:

• Server receives ClientHello.
• Extensions block is parsed (heartbeat, SNI, certificate_status, etc.).
• If the heartbeat extension is enabled and the length field is not validated against the actual payload size, the response builder copies more data than present.
• The extra bytes come from whatever resides after the heartbeat buffer in memory — often private keys, session tickets, or other TLS buffers.

Because mTLS does not alter this flow, any server that runs a vulnerable TLS library and exposes the port without proper mitigations is susceptible to the same OOB read, regardless of whether client certificates are required.

middleBrick performs unauthenticated, black‑box scanning of the API endpoint’s TLS surface. It does not need any client certificate or prior configuration; it simply connects to the target host and port and probes for known unsafe TLS behaviors.

For OOB read detection, middleBrick includes an active heartbeat probe (when the target advertises the TLS heartbeat extension). The scanner sends a HeartbeatRequest with a payload length field set to a value larger than the actual payload (e.g., claiming 100 bytes while sending only 1 byte). If the server replies with more data than the sent payload, middleBrick flags this as a potential information‑leak finding under the Data Exposure category.

The scanner also checks the TLS version and extension set: if the server reports support for the heartbeat extension (extension type 15) and is running a TLS version prior to 1.3, the finding is elevated because TLS 1.3 removed the heartbeat entirely. middleBrick reports the finding with severity, a short description, and remediation guidance, all without needing source code or agents.

Example CLI output (truncated for clarity):

$ middlebrick scan https://api.example.com
...
[DATA EXPOSURE] Potential Heartbleed‑like OOB read detected
- Detail: Server responded with 64 extra bytes to a malformed heartbeat request.
- Severity: High
- Remediation: Disable TLS heartbeat, upgrade to OpenSSL 1.0.1g+ or use TLS 1.3.
- Reference: CVE-2014-0160
...

In a GitHub Action workflow, the same check can be enforced as a gate:

name: API Security Scan
on: [pull_request]
jobs:
  middlebrick:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run middleBrick scan
        uses: middlebrick/action@v1
        with:
          url: https://staging.api.example.com
          fail-below: B   # fail if score drops below B

Thus, middleBrick provides automated, credential‑free detection of OOB read risks in mTLS‑protected endpoints.

Fixing an OOB read in the TLS layer relies on configuring or updating the TLS library so that the vulnerable code path is never executed. The following mitigations are specific to mutual TLS deployments.

• Disable the TLS heartbeat extension. In OpenSSL this can be done at compile time with -DOPENSSL_NO_HEARTBEATS or, at runtime, by setting the SSL_OP_NO_HEARTBEATS option:

SSL_CTX *ctx = SSL_CTX_new(TLS_server_method());
SSL_CTX_set_options(ctx, SSL_OP_NO_HEARTBEATS);
// proceed with mutual TLS setup
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
SSL_CTX_load_verify_locations(ctx, "ca.pem", NULL);
SSL_CTX_use_certificate_file(ctx, "server.crt", SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, "server.key", SSL_FILETYPE_PEM);

• Prefer TLS 1.3, which removed the heartbeat extension entirely. When configuring the server, set the minimum version to TLS 1.3:

// Go example
conf := &tls.Config{
    MinVersion: tls.VersionTLS13,
    ClientAuth: tls.RequireAndVerifyClientCert,
    ClientCAs:  caPool,   // load your CA pool
}
conf.Certificates = []tls.Certificate{cert}
ln, _ := tls.Listen("tcp", ":443", conf)
// serve HTTP over ln

• Keep the TLS library up to date. Vendors regularly patch OOB read issues:
• OpenSSL 1.0.1g (released April 2014) fixes Heartbleed.
• OpenSSL 3.0.8 and later include fixes for CVE-2022-3602 and related punycode bugs.
• BoringSSL and LibreSSL have analogous version checks.

• Validate client certificates strictly. Reject certificates with unknown or malformed extensions before they reach the extension‑parsing code:

// OpenSSL callback to inspect client cert
int client_cert_verify_callback(int ok, X509_STORE_CTX *ctx) {
    if (!ok) return 0; // already failed
    X509 *cert = X509_STORE_CTX_get_current_cert(ctx);
    // Example: reject if certificate contains unsupported extension
    int ext_idx = X509_get_ext_by_NID(cert, NID_id_pe_authorityInfoAccess, -1);
    if (ext_idx != -1) {
        // custom policy: we do not allow AIA in client certs
        return 0;
    }
    return 1;
}
SSL_CTX_set_client_cert_cb(ctx, client_cert_verify_callback);

By disabling heartbeat, enforcing TLS 1.3 or a patched library, and adding strict client‑certificate validation, the OOB read attack surface is removed while preserving the mutual authentication benefits of mTLS.