---
{
  "title": "Adversary in the middle",
  "summary": "An intermediary may observe or alter a communication path.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "IETF: TLS 1.3 specification",
      "url": "https://www.rfc-editor.org/rfc/rfc8446.html"
    },
    {
      "title": "MITRE ATT&CK: Adversary-in-the-Middle",
      "url": "https://attack.mitre.org/techniques/T1557/"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

An adversary-in-the-middle attack places an attacker between communicating parties, potentially allowing observation, modification, or impersonation. Transport encryption and correct certificate validation help protect against network interception. Other cases operate at the application or identity layer, such as a deceptive proxy collecting session credentials. Understand which trust boundary failed before choosing a mitigation; encrypted traffic alone does not make a malicious destination trustworthy.

## In practice

A user ignores a certificate warning and sends credentials through an untrusted intermediary. In another case, a lookalike login proxy relays a real authentication flow and captures the resulting session.

## A common misunderstanding

HTTPS establishes protection to the selected endpoint; it does not guarantee that you selected the intended service.

## Check your understanding

What does certificate validation contribute?

**Think it through:** It checks whether the endpoint identity matches the intended destination under the configured trust model.


## Trust must connect the user to the intended peer

An intermediary attack places an unauthorized party in a communication path. The effect can include reading, changing, or relaying information, depending on the protocol and access. Correctly configured authenticated encryption helps protect a network channel, but the endpoints still need to identify the intended service and handle credentials appropriately.

A valid certificate for a deceptive domain does not make that domain the real service. Some phishing proxies operate at an application or identity layer and relay interactions while presenting their own endpoint to the victim. Distinguish that scenario from an attacker silently decrypting a correctly validated connection to the genuine service.

## A fictional sign-in relay

An academy employee reaches a convincing login page at the wrong address. Identity records later show unexpected session use. Analysts preserve the message or navigation source, domain context, browser and identity events, and subsequent activity. They do not infer the exact relay mechanism from the login page's appearance alone.

Network interception scenarios can involve different evidence, such as route changes, trust-store modifications, certificate warnings, or unauthorized proxy configuration. Legitimate enterprise proxies also exist. Review approval and actual behavior before calling every intermediary malicious. Never instruct users to bypass certificate warnings as a routine troubleshooting step.

## Compare two trust failures

Draw one fictional connection to the correct service with certificate validation failing, and another to a deceptive domain with a valid certificate for that domain. Explain why both require attention for different reasons. Identify one user-verification improvement and one technical protection appropriate to each.

Response should consider credential and session exposure where supported by evidence, using the service's official revocation and recovery procedures. Encryption remains essential, but its protection is bounded by endpoint trust and the application's design. A secure transport to the wrong party does not establish the intended business relationship.

## Keep exploring

- [[tls]]
- [[digital-certificates]]
- [[sessions-and-cookies]]
- [[phishing]]