Detecting Man-in-the-Middle (MITM) Attacks Against HAProxy Reverse Proxy Infrastructure Through Secure TLS Communication Architecture

Enterprise applications commonly use reverse proxies to control access between users and backend application services. Reverse proxies can provide centralized TLS termination, traffic routing, access control, and security enforcement.

If encrypted communication is not properly designed or certificate validation is weak, an attacker positioned between a client and the reverse proxy may attempt a Man-in-the-Middle (MITM) Attack to intercept or modify application traffic.

In this use case, HAProxy is deployed on Ubuntu Linux as the controlled enterprise reverse-proxy infrastructure inside an isolated VirtualBox laboratory. A backend web application is placed behind HAProxy to represent an enterprise application architecture.

A controlled Man-in-the-Middle (MITM) Attack is simulated from Kali Linux against the isolated environment.

The assessment focuses on determining whether the enterprise communication architecture properly protects traffic between clients, the HAProxy reverse proxy, and backend application services.

HAProxy, OpenSSL, Bettercap, Wireshark, and nftables are used to establish, test, monitor, and secure the TLS communication architecture.

The proposed defensive architecture implements TLS encryption, certificate validation, secure TLS configuration, controlled communication paths, network segmentation, and traffic monitoring.

After implementing the security controls, the MITM assessment is repeated to verify that intercepted or modified communication cannot be successfully substituted or trusted while legitimate encrypted application communication continues to function.

HAProxy provides the controlled reverse-proxy infrastructure used to represent an enterprise application-access architecture. The laboratory environment contains Client Endpoint → Encrypted HTTPS Connection → HAProxy Reverse Proxy → Backend Application Server → Enterprise Application. The HAProxy layer is intended to provide a trusted communication boundary between clients and backend application services.

A Man-in-the-Middle (MITM) Attack attempts to position an attacker between two communicating systems and intercept, observe, or modify their communication.

The security problem can occur when TLS encryption is not properly enforced, weak TLS protocols or cipher configurations are allowed, certificates are not properly validated, clients accept untrusted certificates, certificate trust is not centrally managed, backend communication is unnecessarily unencrypted, network segmentation is weak, security monitoring does not identify unexpected interception behavior, or reverse-proxy communication paths are not properly controlled. If these architectural weaknesses exist, an attacker may attempt to intercept HTTPS communication and present an unauthorized certificate or modify traffic between the client and the reverse proxy.

The security problem is therefore:

The proposed solution introduces mandatory TLS communication, strong TLS configuration, certificate-based trust, controlled certificate management, secure client-to-proxy communication, secure proxy-to-backend communication where required, network segmentation, firewall-based communication control, and TLS traffic monitoring.

A Man-in-the-Middle (MITM) Attack attempts to place an unauthorized system between a legitimate client and the destination service. In this controlled assessment, the attacker attempts to intercept communication between the test client and the HAProxy reverse proxy. The assessment is performed exclusively within the isolated laboratory.

The assessment focuses on identifying unexpected TLS certificates, certificate trust failures, weak TLS configuration, unencrypted communication paths, unexpected network intermediaries, modified application traffic, unauthorized communication paths, and TLS negotiation weaknesses.

Enterprise applications should use a trusted encrypted communication architecture between clients, reverse proxies, and backend services.

The security architecture follows: Client → TLS Encryption → HAProxy → Controlled Backend Connection → Application.

The secure processing flow is: