A Man in the Middle Poses as Both Ends of Your Connection

You join a network, the pages load, and nothing looks wrong. Reading what goes past is the version of the risk that is easy to picture. The version that is harder to defend against is somebody answering, in the site’s name, and relaying the real conversation behind it.

Reading is passive, answering is not

The distinction has a formal home. RFC 4949, the IETF’s security glossary, sorts attacks by what they do to a system rather than by how sophisticated they are. A passive one “attempts to learn or make use of information from a system but does not affect system resources of that system”. An active one “attempts to alter system resources or affect their operation”, and RFC 3552 marks the boundary by the act itself: “When an attack involves writing data to the network, we refer to this as an ACTIVE ATTACK.”

RFC 3552 is the IETF’s guidance to its own authors on how to write a specification’s security considerations, published in July 2003, and section 3.3.5 sets out the attack in question. “The attacker subverts the communication stream in order to pose as the sender to receiver and the receiver to the sender.” Two conversations rather than one, with the same party holding an end of each.

Then the sentence that separates this from being overheard. Section 3.3 works through replay, message insertion, message deletion and message modification before arriving here, and the man in the middle “differs fundamentally from the above forms of attack because it attacks the identity of the communicating parties, rather than the data stream itself”. The RFC draws the consequence immediately: “many techniques which provide integrity of the communications stream are insufficient to protect against man-in-the-middle attacks.” It also names the condition that makes it possible at all, which is a protocol that “lacks PEER ENTITY AUTHENTICATION”.

The local route runs on a design from 1982

On your own network, an IPv4 packet is not sent to an IP address. It is sent to a hardware address, and something has to supply the link between the two. That something is the Address Resolution Protocol, written down in November 1982 as RFC 826, and it works by putting the question to every station on the wire and believing what comes back.

The reception algorithm is where the weight sits, and the document states it rather than glossing it. A host files the sender’s pairing into its own table before it looks at whether the packet was a question or an answer, which the RFC flags in terms and then justifies on the assumption that communication is bidirectional. So an answer nobody asked for still counts. The replacement rule is just as plain: where an entry for that sender already exists, “the new hardware address supersedes the old one”.

RFC 3552 does not treat the consequence as theoretical. It calls it “trivial to mount man-in-the-middle attacks on local networks via ARP spoofing”, describes the method as forging “an ARP with the victim’s IP address and his own MAC address”, and notes that “Tools to mount this sort of attack are readily available.”

Nothing is being broken there. The protocol has no way to separate a true answer from a false one, because it carries nothing to check an answer against.

The other route is that you joined it

The second way into the path needs no protocol weakness whatsoever. Whoever runs a network is in the path of every device that joins it, and that is the arrangement working rather than failing. What turns it into an attack is the network not being the thing its name suggests, which is one of the risks that come with a shared network.

What a device accepts at the moment it joins is more than an address. The same reply supplies the router to send traffic through and the resolver to ask about names, and the negotiation that hands all of that over follows the exchange one message at a time. Take the configuration and you have taken the route with it.

What the position does not get you

A relay sitting in the path is in a weaker spot than the phrase suggests, for the reason RFC 3552 already gave. Secrecy does not defeat this attack and neither does tamper-detection. Peer entity authentication does, which means the far end proving which end it is, and what the HTTPS guarantee covers takes that guarantee apart promise by promise.

The arrangement is also cheaper than you might expect. “Note that it is only necessary to authenticate one side of the transaction in order to prevent man-in-the-middle attacks,” says RFC 3552, and it names web commerce as exactly that case, one where only the server needs authenticating. A relay that cannot produce a valid certificate for the name in your address bar gets no readable copy of your session. It gets a failed handshake, and you get a warning.

The play is to keep TLS out of it altogether

Which pushes the attack somewhere else. If the guarantee holds once it is running, the move is to stop it starting.

RFC 7457, the IETF’s February 2015 summary of known attacks on TLS, names the family in section 2.1. Such attacks “attempt to remove the use of Secure Socket Layer / Transport Layer Security (SSL/TLS) altogether by modifying unencrypted protocols that request the use of TLS, specifically modifying HTTP traffic and HTML pages as they pass on the wire”. The relay answers you over plain HTTP, rewrites the links that would have moved you to the encrypted version, and holds the encrypted conversation with the real site itself. No certificate ever reaches your browser, so there is no failed handshake to raise.

The RFC attaches a condition, and it is the useful part: “these attacks are only effective if the client initially accesses a Web server using HTTP”. The opening is the first request, made before any of the protection is in force, and where the guarantee starts covers that opening and the instruction a site sends to close it.

Where the real check sits

Two things are checkable here, and they are not equally strong.

The certificate is the check, and your browser has already run it. The question worth asking is whether it came back clean. A warning you clicked through is that check working and then being overruled by hand.

The two tools on this site answer something narrower, and it is worth being exact about what. What your own connection presents names the address a site sees and the provider behind it, and the page’s own list of what might have issued that address reads “internet provider, mobile network, company network, VPN, proxy, or hosting provider”. On a network you did not set up, a provider you cannot account for is a reason to look twice. How your connection looks to reputation data goes a step further and reports how that data reads the address: as a datacentre or hosting range, as a VPN or a proxy, as a Tor exit, or as one carrying abuse reports.

Neither of them detects a relay, and saying otherwise would be the easiest overclaim on the page. Both report the same thing about a corporate proxy, a provider translation layer or a VPN somebody left running, and the proxy check makes the point on its own page: a flag of that kind “does not mean anything is wrong with your connection or your intentions”. What the pair answers is whose network your traffic is leaving through. That is a smaller question than whether anyone is standing in the path, and a reasonable one to have answered first.

The reason this attack reads differently from being overheard is that it is aimed at identity rather than at content, and the defence has to be aimed at the same place. Encryption in the path does not settle it on its own. Something has to establish which end is which, and on the web that something is a certificate that matches the name you typed.