Arp Spoofing in Hapi with Mutual Tls

Arp Spoofing is a Layer 2 attack where an adversary sends falsified Address Resolution Protocol messages to associate their MAC address with the IP of a legitimate host, such as a server or another client. In a Hapi server deployment that uses Mutual TLS (mTLS) for transport-layer authentication, Arp Spoofing does not break the TLS handshake itself, because mTLS operates above Layer 3 and relies on certificates and cryptographic verification. However, the combination introduces nuanced risks in practice.

Consider a scenario where a Hapi service and its clients perform mTLS with strict certificate validation. An attacker on the same local network segment can still execute Arp Spoofing to redirect traffic intended for the Hapi server to their machine. The attacker’s host will not present a valid client certificate when the intercepted TLS connection attempts to complete the handshake; therefore, the Hapi server will reject the connection if mTLS verification is enforced. This means that Arp Spoofing alone does not bypass mTLS authentication when the server is configured to require and validate client certificates on every connection.

Where exposure can occur is in implementations that inadvertently allow unauthenticated or weakly authenticated paths alongside mTLS-protected routes, or where certificate validation is inconsistent. For example, if the Hapi server has a health-check endpoint that skips client certificate verification for convenience, Arp Spoofing can redirect traffic to that less-protected endpoint, enabling unauthorized access or traffic interception. Additionally, if a client fails to validate server certificates properly (e.g., skips hostname verification or accepts self-signed certs without pinning), an attacker conducting Arp Spoofing might present a server certificate that the client erroneously trusts, leading to a man-in-the-middle scenario despite the presence of mTLS.

Another subtle risk involves session hijacking after successful authentication. Once a client has established a valid mTLS session and received an application-level token or cookie, Arp Spoofing could allow the attacker to observe and replay that token on a different network path if other protections (like strict transport security and token binding) are absent. The mTLS layer secures the initial handshake, but does not inherently prevent replay of authorized application tokens if the broader deployment lacks anti-replay mechanisms and network-level isolation.

It is important to recognize that while mTLS significantly raises the bar compared to unencrypted or singly authenticated channels, the network topology and implementation details matter. If hosts are on shared or untrusted subnets, Arp Spoofing can still disrupt or intercept sessions that rely on weak configurations, such as missing certificate revocation checks or inconsistent cipher suite enforcement across endpoints. Therefore, deploying Hapi with Mutual TLS should be complemented with network segmentation, host-level security, and strict validation of both server and client certificates to mitigate the relevance of Arp Spoofing in the threat model.

To securely implement Mutual TLS in Hapi, enforce client certificate validation and avoid any optional or skipped verification. Below are concrete, syntactically correct examples using the built-in tls module and Hapi server configuration.

Example 1: Hapi server with strict mTLS, requiring and verifying client certificates.

const Hapi = require('@hapi/hapi');
const fs = require('fs');

const server = Hapi.server({
  port: 443,
  tls: {
    key: fs.readFileSync('/path/to/server-key.pem'),
    cert: fs.readFileSync('/path/to/server-cert.pem'),
    ca: fs.readFileSync('/path/to/ca-cert.pem'),
    requestCert: true,
    rejectUnauthorized: true
  }
});

server.route({
  method: 'GET',
  path: '/api/secure',
  handler: (request, h) => {
    // request.socket.getPeerCertificate() can be used for additional verification
    return { message: 'Authenticated via mTLS' };
  }
});

server.start().catch(err => {
  console.error('Server failed to start:', err);
  process.exit(1);
});

In this configuration, requestCert: true asks clients to present a certificate, and rejectUnauthorized: true ensures that the server rejects connections if the client certificate is not signed by the trusted CA, is expired, or fails hostname/purpose checks.

Example 2: Client making an mTLS request to Hapi using node-fetch.

const fetch = require('node-fetch');
const https = require('https');

const agent = new https.Agent({
  cert: fs.readFileSync('/path/to/client-cert.pem'),
  key: fs.readFileSync('/path/to/client-key.pem'),
  ca: fs.readFileSync('/path/to/ca-cert.pem'),
  rejectUnauthorized: true
});

fetch('https://localhost:443/api/secure', { agent })
  .then(res => res.json())
  .then(data => console.log(data))
  .err(err => console.error('Client error:', err));

Ensure the client’s certificate is signed by the same CA that the server trusts, and that revocation is checked via CRL or OCSP depending on operational requirements. For production, pin certificates or use short-lived certificates issued by a private CA to further reduce the impact of compromised credentials.

Additionally, avoid mixed configurations where some routes or handlers skip TLS verification. Validate certificate details in your route handlers if needed (e.g., inspect serial number or extended key usage), but do not rely on this as a substitute for proper TLS-level enforcement. Combine these measures with network controls and continuous monitoring to reduce the practical impact of Arp Spoofing in your Hapi deployments.