Why Replies Change the Threat Model

A two-way proxy changes the open-tunnelling-host problem because it gives an attacker feedback, not merely a place to send packets. The focus here is the return path created by global-address translation: what the target sees, what the remote sender can establish, and how two such proxies can be made to forward traffic toward one another. The practical judgment is to separate bidirectional reachability from unlimited impersonation, then assess the loop’s impact against its path and filtering conditions.

A one-way proxy can make a packet appear to come from an intermediary, but the sender may never see the target’s response. A two-way proxy closes that gap. The endpoint translates traffic in a way that lets replies return to the sender, while the target still sees the endpoint’s address. That extra direction is a small change in packet flow with a large change in what an attacker can attempt.

A reply path changes what the endpoint can do

The paper defines a two-way proxy as a NAT-enabled open tunnelling host that can forward received replies to the attacker. The host still begins with the same basic weakness: it accepts an encapsulated packet from an arbitrary source and processes the inner traffic. The difference is what the gateway does afterward. Its address translation creates a usable mapping between the traffic arriving through the tunnel, the remote target, and the sender who is waiting for a response.

This is not the same as a conventional application proxy. No service necessarily parses the application protocol on behalf of the sender. The endpoint operates at the network and transport path, translating addresses and forwarding packets. It becomes “two-way” because the state maintained by the gateway is sufficient for a reply to travel back through the endpoint to the person who initiated the exchange.

The target’s view remains important. In the paper’s handshake demonstration, the attacker sends traffic through the two-way proxy toward a selected target. The proxy changes the apparent source so the target sees the proxy’s public address. When the target responds, the proxy translates and forwards the reply toward the attacker. To the target, the connection appears to involve the proxy; to the attacker, the proxy is a relay that supplies both directions of the exchange.

That arrangement can let the attacker complete a TCP handshake and then deliver application-layer payloads or conduct application-layer denial of service while remaining anonymous to the target. “Anonymous” here is relative to the target’s network view. The target sees the proxy’s address, not the attacker’s direct address. It does not mean that the attacker has disappeared from every observation point, that the proxy cannot be identified, or that every application will accept the resulting connection.

The paper also places a clear limit on the identity that can be presented. The attacker cannot establish the connection with an arbitrary spoofed source address; the proxy’s own address is the visible identity. The handshake attack additionally requires the proxy to be able to spoof the target’s address in the relevant reply path.