What is Man-in-the-middle attack (MITM)?
A man-in-the-middle attack occurs when an adversary places itself between two parties to intercept, relay, or change their communication without their knowledge. TLS can protect against this attack only when each endpoint validates the peer identity it expects and rejects invalid certificates or keys. Encryption without authenticated peer identity can still connect a client to an attacker. Certificate pinning can reduce some trust risks, but it adds key-rotation and recovery risk. A hosted service is not inherently a man-in-the-middle attack.
Why it matters
An attacker on the request path can impersonate an endpoint, read private data, or change traffic. Authenticated encryption makes this attack harder by binding the protected channel to a verified peer identity.
How it works
- An attacker places a system between two endpoints or redirects one endpoint to an attacker-controlled service.
- During the TLS handshake, the client validates the server certificate, expected name, signature, and trust chain. Mutual TLS also validates a client certificate.
- The endpoints derive session keys and use authenticated encryption. A failed identity or integrity check stops the protected connection.
Example
A user opens an internal admin site through Pomerium after a hostile network changes DNS. The browser rejects an attacker certificate that does not validate for the expected Pomerium host.
Pomerium boundary
Pomerium terminates the downstream TLS connection and creates a separate connection to the upstream service. Route TLS settings can validate a private upstream certificate authority and expected server identity. Pomerium can also present a client certificate when the upstream service requires mutual TLS.
Limits and non-claims
- TLS protects a channel between its endpoints. A TLS-terminating proxy or a compromised endpoint can still read plaintext data.
- A compromised trusted certificate authority, stolen private key, or incorrect trust store can defeat peer authentication.
- Skipping certificate verification or accepting the wrong server name removes an essential defense against this attack.
Evaluation checklist
- Which two peers intend to communicate, and where can the attacker intercept or redirect traffic?
- Do both peers validate the expected name, credential, channel, freshness, and protocol version?
- Can proxy termination, added trust roots, downgrade, or skipped validation create an accepted false peer?
