Cache Poisoning with Mutual Tls

Cache poisoning in Mutual TLS environments exploits the trust established through client certificate authentication. When a client presents a valid certificate, the server may cache responses based on the assumption that the authenticated identity is the only one who should access that data. This creates a vulnerability when attackers can manipulate cache keys or predict cache behavior.

The most common attack pattern involves certificate-based session hijacking. An attacker obtains a valid client certificate through various means—compromise, reuse of expired certificates, or exploitation of weak certificate validation. Once they have a certificate, they can request resources that should be cached per-user. If the cache key generation doesn't properly incorporate certificate details or if the caching layer sits outside the Mutual TLS boundary, responses meant for one client can be served to another.

Consider a Mutual TLS API that serves user-specific data. The server validates the client certificate, authenticates the user, and returns sensitive information. If this response is cached without proper key differentiation, subsequent requests from different clients with different certificates might receive cached data intended for the original requester. This is particularly dangerous in shared infrastructure environments where multiple services share caching layers.

Another manifestation occurs during certificate rollover periods. When certificates are updated or renewed, caching systems might still serve responses cached under the old certificate's context. Attackers can exploit this by using expired certificates to access cached data that should no longer be available to them. This creates a window of opportunity where data persistence in caches violates the principle of certificate-based access control.

Mutual TLS-specific cache poisoning also appears in API gateway configurations. Many gateways terminate TLS connections and then proxy requests to backend services. If the gateway caches responses based on simplified request characteristics while the backend performs fine-grained authorization based on certificate details, the caching layer can become a bypass mechanism. The gateway might cache a response for a high-privilege certificate and serve it to a lower-privilege certificate that shouldn't have access to that data.

Time-based cache poisoning is another concern. Certificate validation often includes time checks, but cache expiration policies might not align with certificate validity periods. An attacker could use a certificate that's valid for a short window to populate caches with sensitive data, then continue accessing that data through the cache even after the certificate expires, if the cache entries haven't expired yet.

The complexity increases when Mutual TLS is combined with mutual authentication at application layers. For example, a service might validate a client certificate, then use that identity to make downstream requests to other services, each with their own Mutual TLS connections. If any layer in this chain caches responses inappropriately, it can lead to data leakage across the entire trust boundary.

Detecting cache poisoning in Mutual TLS environments requires examining both the certificate validation process and the caching implementation. The first step is to verify that cache keys incorporate sufficient certificate attributes. Simply using the certificate's subject DN or serial number might not be enough—you need to ensure that all relevant certificate properties that affect authorization are included in cache key generation.

Network traffic analysis can reveal suspicious patterns. Monitor for requests where the client certificate changes but the response content remains identical to a previous response for a different certificate. This suggests that the cache is serving data without proper certificate-based differentiation. Tools that can inspect Mutual TLS traffic, such as Wireshark with appropriate decryption keys, are essential for this analysis.

Runtime scanning with middleBrick can identify cache poisoning vulnerabilities specific to Mutual TLS configurations. The scanner tests whether cached responses vary appropriately based on client certificate properties. It attempts to access cached endpoints using different certificates and verifies that responses are correctly isolated per-certificate identity. The scanner also checks for certificate attribute leakage in cache keys, which could allow attackers to predict or manipulate cache behavior.

Code review should focus on the intersection of certificate validation and caching logic. Look for patterns where certificate validation occurs but the resulting authentication context isn't properly propagated to caching layers. Pay special attention to middleware that handles Mutual TLS termination—these components often sit between the certificate validation and the application logic, creating opportunities for cache poisoning if not implemented correctly.

Certificate lifecycle management is another critical detection area. Monitor for certificates that remain valid in caches after they've expired or been revoked. This can happen when cache expiration policies don't align with certificate validity periods. Implement logging that tracks certificate usage patterns and correlates them with cache hits to identify anomalies.

Testing should include certificate substitution attacks. Have authorized users access sensitive endpoints, then attempt to access the same endpoints using different but valid certificates. If the system serves cached responses meant for other users, you've identified a cache poisoning vulnerability. This testing should cover various certificate properties including issuer, subject alternative names, and extended key usage attributes.

API gateway configurations require special attention. Many gateways cache responses at the edge while performing certificate validation deeper in the infrastructure. Verify that the gateway's cache key generation incorporates all certificate attributes that affect downstream authorization decisions. Test scenarios where certificate validation passes at the gateway but would fail at backend services due to more granular authorization rules.

Effective remediation of cache poisoning in Mutual TLS environments requires architectural changes that ensure certificate-based isolation at every caching layer. The fundamental principle is that cache keys must incorporate all certificate attributes that affect authorization decisions. This means going beyond simple subject DN inclusion to incorporate serial numbers, issuer details, and any certificate extensions that influence access control.

Here's a Node.js example using Express and a caching layer:

const express = require('express');
const redis = require('redis');
const client = redis.createClient();
const app = express();

// Middleware to extract certificate details
function extractCertDetails(req, res, next) {
  const cert = req.connection.getPeerCertificate();
  if (!cert.authorized) {
    return res.status(403).json({ error: 'Invalid certificate' });
  }
  
  // Create a comprehensive cache key
  req.cacheKey = `api:${cert.subject.hash}:${cert.serialNumber}:${cert.issuer.hash}`;
  next();
}

app.use(extractCertDetails);

app.get('/user-data', async (req, res) => {
  try {
    // Check cache first
    const cached = await client.get(req.cacheKey);
    if (cached) {
      return res.json(JSON.parse(cached));
    }
    
    // Fetch user data based on certificate identity
    const userData = await fetchUserDataFromCert(req.connection.getPeerCertificate());
    
    // Cache with proper TTL and key
    await client.setex(req.cacheKey, 300, JSON.stringify(userData));
    res.json(userData);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

function fetchUserDataFromCert(cert) {
  // Implementation that uses certificate details to fetch data
  // This would query your user database or service
  return new Promise((resolve) => {
    // Simulate database lookup based on certificate
    resolve({
      userId: cert.subject.CN,
      permissions: ['read', 'write'],
      data: 'User-specific sensitive information'
    });
  });
}

app.listen(3000);

For NGINX-based Mutual TLS setups with caching, the configuration should include certificate details in cache keys:

server {
    listen 443 ssl http2;
    server_name api.example.com;
    
    ssl_certificate /path/to/server.crt;
    ssl_certificate_key /path/to/server.key;
    ssl_client_certificate /path/to/ca.crt;
    ssl_verify_client on;
    
    # Custom cache key incorporating certificate details
    proxy_cache_key "$scheme$request_method$host$request_uri$ssl_client_serial";
    
    location /api/ {
        proxy_pass http://backend-service:8080;
        proxy_cache my_cache;
        proxy_cache_valid 200 10m;
        
        # Ensure certificate is passed to backend
        proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
        proxy_set_header SSL_CLIENT_VERIFY $ssl_client_verify;
        proxy_set_header SSL_CLIENT_S_DN $ssl_client_s_dn;
    }
}

API gateway implementations require similar attention. Here's a Kong configuration example:

local certificate = kong.request.get_ssl_client_cert()
if not certificate then
  return kong.response.exit(403, { message = "Client certificate required" })
end

-- Create cache key with certificate details
local cache_key = string.format(
  "api:%s:%s:%s",
  kong.request.get_path_url(),
  certificate.serial,
  certificate.issuer.hash
)

-- Check cache
local cache_client = kong.cache.get_cache_client()
local cached_response = cache_client:get(cache_key)
if cached_response then
  return kong.response.exit(200, cached_response)
end

-- Process request and cache response
local response = handle_request()

-- Cache with proper isolation
cache_client:set(cache_key, response.body, { ttl = 600 })

Time-based cache poisoning requires alignment between certificate validity and cache expiration. Implement certificate-aware TTL policies where cache entries expire when certificates become invalid. This might involve periodic cache cleanup jobs that check certificate revocation status and remove entries for expired or revoked certificates.

For distributed systems with multiple Mutual TLS layers, ensure consistent cache key generation across all layers. A certificate valid at the edge gateway should produce the same cache key as it would at backend services, preventing cache poisoning through layer bypassing. Consider using cryptographic hashing of certificate details for cache keys to prevent information leakage while maintaining uniqueness.

Monitoring and alerting should be implemented to detect cache poisoning attempts. Log cache key generation details and monitor for unusual patterns like cache hits from certificates that shouldn't have access to certain data. Set up alerts for cache key collisions or for cache entries that persist beyond certificate validity periods.