Step 162. Proxies and Anonymity — The Art of Hiding Behind a Stand-In, and Its Limits

Level 2 — Network Attacks and MITM | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Step 132 (intercepting with the Burp Suite proxy) and Step 85 (HTTP vs HTTPS) complete.

What you need: a concept chapter — paper and pen (or a diagram tool) are enough. It’s helpful to have Step 132’s mini proxy code open again.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Caution: anonymization technology is also a shield protecting journalists and activists in oppressive environments, but it is not a shield for illegal acts — and as you’ll learn today, a perfect shield does not exist. This chapter is concept-focused; the proxy relay log re-quotes Step 132’s measurement (2026-09-09).

In Step 132 you used a proxy as "a tool that intercepts requests to look at them." Today you look at the same structure from the opposite direction — the proxy as a tool that hides my IP from the server, and Tor, which pushes that idea to the extreme. We’ll organize how the simple structure of "someone who makes the request on my behalf" becomes the infrastructure of tracking evasion, and why even that infrastructure is not complete. Knowing the limits of anonymity is the condition for using anonymity correctly.

1. Learning Objectives

By the end of this chapter, you will be able to:

Explain the difference between a forward proxy and a reverse proxy by "whom it represents"
Explain the principle by which a proxy hides your IP from the server — and why the proxy sees that much in return
Explain the structure of proxy chains and proxychains
Explain Tor’s triple-relay (onion routing) structure and what each node knows
Enumerate the factors that break anonymity (exit-node eavesdropping, fingerprinting, timing analysis, behavioral habits)

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Concept chapter — Step 132’s Python mini proxy (for re-confirming the principle)
Today’s concepts	forward/reverse proxies, HTTP vs SOCKS proxies, proxy chains, Tor (guard-middle-exit nodes), browser fingerprinting
Concepts needed	Step 132’s proxy relay structure, Step 85’s plaintext/ciphertext, the relationship between IP addresses and identity
Today’s artifact	a structure diagram per proxy type + a Tor identity-protection table + a summary of anonymity’s limits

2-1. Forward Proxy — The Client’s Stand-In

A proxy is a "stand-in." A forward proxy represents the client. Instead of my browser going to the server directly, it asks the proxy; the proxy goes on my behalf with its own IP and brings back the result. The server’s log records the proxy’s IP, not mine.

There are three uses. ① Hiding — so the server doesn’t learn my address. ② Bypassing — going out through a company/school network’s exit, or dodging region restrictions. ③ Observing — like Step 132’s Burp, watching what passes through. The same structure becomes a defense tool, a bypass tool, or an attack tool depending on the purpose.

2-2. Reverse Proxy — The Server’s Stand-In

There’s also the reverse proxy, which runs in the opposite direction. This one represents the server. The user thinks they connected to example.com, but what actually answered was a front-end reverse proxy (like nginx or Cloudflare), and the real server hides behind it. Server administrators gain load balancing, a reduced attack surface, and TLS termination from this. If a forward proxy is "a tool that hides me," a reverse proxy is "a tool that hides the server."

There’s one way to tell them apart — who chose the stand-in. If the client chose it, it’s a forward proxy; if the server chose it, it’s a reverse proxy.

2-3. HTTP Proxies and SOCKS Proxies

There are also kinds in how you ask the stand-in. An HTTP proxy understands only web requests — a way of asking "fetch this URL for me." A SOCKS proxy (SOCKS5 is the current standard) works one floor down — you ask "open me a connection to this address and port," so it carries any TCP traffic, web or SSH or anything else. This is why proxychains and Tor use SOCKS.

2-4. Tor — A Structure Where Three Stand-Ins Relay

A single proxy has a fatal weakness: that proxy knows both me and the destination. If the proxy operator keeps logs, anonymity is over. Tor (The Onion Router) solves this by "splitting the stand-in into three."

Guard node: knows my IP, but not the destination.
Middle node: knows only the previous and next hop — neither me nor the destination.
Exit node: talks to the destination server, but doesn’t know my IP.

Data is encrypted in three layers like an onion, and each node peels off only its own layer and passes it to the next — hence onion routing. It’s designed so that no single node knows all of "who, with whom, and what."

2-5. The Limits of Anonymity — Tor Is Not Invincible

Even so, there are points where it collapses.

Exit-node eavesdropping: from the exit to the destination is the regular internet. If that stretch is plaintext HTTP, the exit operator reads the content (which is why HTTPS is essential even inside Tor).
Browser fingerprinting: even with your IP hidden, your browser’s combination of screen size, fonts, and plugins can be a fingerprint few in the world share.
Timing analysis: a powerful observer who can watch both the entry and the exit simultaneously estimates the path by correlating when packets went in and when they came out.
Behavioral habits: the moment you log into your usual account over Tor, you’ve thrown anonymity away yourself. Not technology but habit — the most common path of collapse.

2-6. How Is a VPN Different from a Proxy?

Let’s address the VPN (Virtual Private Network), a frequent comparison. A commercial VPN is technology that "connects my device and the VPN company’s exit server with an encrypted tunnel." Two differences from a proxy. ① The layer it works at — a proxy is asked per application (browser), but a VPN puts all of the OS’s traffic wholesale into the tunnel. ② The relationship — the VPN company is "one trusted proxy" that knows my IP and every destination.

So the picture organizes like this: you merely move the carrier’s gaze to the VPN company; the total amount of anonymity doesn’t grow — it’s a choice of "where to place trust." If Tor is the extreme that splits even that trust three ways, a commercial VPN is the compromise that chose convenience and speed. Training yourself to compare the three (direct, VPN, Tor) by "who knows what" is the extension of today’s table.

3. Follow Along

3-1. What a Proxy Sees — Re-reading Step 132’s Measurement

To understand the price of anonymization, you first have to see a proxy’s field of view. Here’s the log from Step 132, when we ran the 30-line mini proxy and sent a request through it with curl (Step 132 3-4, re-quoted from the 2026-09-09 measurement):

[Proxy started] 127.0.0.1:8080 — waiting for requests
[Connection accepted] 127.0.0.1:xxxxx
POST /login HTTP/1.1
Host: 127.0.0.1:5000
...
username=hacker&password=mypw123

How to read it: the proxy saw the entire request — the destination, the headers, even the password in the plaintext body. Read this log backwards. "A proxy that hides my IP from the server" is simultaneously "a position that can see every request I make." Entrusting your anonymity to a free proxy is like subscribing a stranger to your communications. This is today’s starting point.

3-2. Drawing Structure Diagrams — By the Number of Stand-Ins

Draw three structures on paper.

[Direct connection]
Me (my IP) ───────────────→ Server          Server log: my IP

[One proxy]
Me ──→ Proxy (proxy IP) ──→ Server          Server log: proxy IP / Proxy log: my IP + destination + content (when HTTP)

[Proxy chain]
Me ──→ P1 ──→ P2 ──→ P3 ──→ Server           Server log: P3's IP / to trace, you must obtain ALL of P1~P3's logs

How to read it: every time an arrow is added, the number of logs a tracker must collect grows, and the more those logs are scattered across different countries and providers, the harder collection becomes. proxychains is merely a tool that assembles this chain in the order written in /etc/proxychains.conf — there’s no magic; the structure is the principle.

3-3. Building Tor’s Identity-Protection Table

Organize 2-4’s triple relay by "what each node knows." Filling in this table yourself is today’s core training.

Observer	My IP	Destination server	Content (HTTPS)	Content (plaintext HTTP)
My ISP	Knows (the fact that I use Tor)	Doesn’t know (only sees the Tor entry)	Doesn’t know	Doesn’t know (Tor stretch is encrypted)
Guard node	Knows	Doesn’t know	Doesn’t know	Doesn’t know
Middle node	Doesn’t know	Doesn’t know	Doesn’t know	Doesn’t know
Exit node	Doesn’t know	Knows	Doesn’t know	Knows
Destination server	Doesn’t know (only sees the exit IP)	Itself	Its own pages	Its own pages

How to read it: look at the last row and the fourth row. Even with Tor, plaintext HTTP content is exposed to the exit node, and the server knows "which Tor exit you came from." What Tor hides is the connection’s starting point (my IP) — not the existence of the communication or the content of plaintext.

3-4. Limit-Scenario Analysis — Where Does It Collapse?

Evaluate these three scenarios yourself (the answers are in Section 5).

You connected over Tor and logged into your usual email.
Instead of the Tor Browser, you used your everyday Chrome (logged in, 10 extensions) with only a proxy attached.
You reached the exit node over HTTPS, but an observer is watching both entry and exit traffic in the same time window.

How to read it: the common thread is "factors outside Tor." The onion encryption worked perfectly, yet login habits, browser fingerprints, and two-end observation gave identity away. Anonymity is not a property of the tool — it’s a property of your entire operational habit.

Set yourself one criterion for evaluation: "Does this action connect back to the usual me?" #1 connects through the account, #2 connects through the browser fingerprint and login cookies, #3 connects through time correlation. None of the three broke the technology — they all left a connecting thread.

3-5. Defensive Uses — Why We Learn This

Reading these technologies only as "how attackers hide" is half the story. From the defender’s seat, it flips like this.

Checking whether an IP in a breach log is a proxy/Tor exit is the first step of tracing (public lists of Tor exits exist).
"The attacker used a proxy = can’t catch them" is wrong. Finding which link in the chain kept logs, and where behavioral habits leaked, is the substance of tracing.
A reverse proxy is a legitimate shield protecting your server — in practice it becomes the basic fitness for WAFs and load balancing.

3-6. Filling In the Direct vs VPN vs Tor Comparison Table

The final exercise. Measure the three connection methods with the same ruler. Don’t copy the table — fill it in first, then compare.

Criterion	Direct connection	Commercial VPN	Tor
IP the server sees	My IP	VPN exit IP	Tor exit IP
What the ISP knows	Every destination	The fact "they use a VPN"	The fact "they use Tor"
Who knows everything	No one (but the carrier sees the path)	The VPN company	No one (split three ways)
Speed	Fast	Slightly slower	Slow
Trust point	Carrier + entire path	One VPN company	None (distributed)

How to read it: it’s not "which side is unconditionally safe" — "who you give how much trust" differs. A VPN is the choice of concentrating trust in one company instead of the carrier, Tor is the choice of giving everything to no one, and direct connection is the choice of doing neither. The reason the right answer changes with the purpose (work network access, censorship circumvention, identity protection) is in this table.

4. Missions & Exercises

Mission — An Anonymity Evaluation Report

Draw the three structure diagrams of 3-2 yourself, and under each drawing write two lines: "what the server knows / what the stand-in knows."
Refill the 3-3 table from blank (without looking). After filling it, compare with the text and annotate the cells you got wrong with reasons.
Virtual scenario: "Your company’s log shows account-takeover attempts of the same account arriving from 30 Tor exit IPs." Write three things to check when tracing this attack.
Divide free proxy services into "uses you must never use them for" and "uses that are acceptable," and set a judgment criterion grounded in 3-1’s log.

Exercises

Exercise 1. Distinguish forward and reverse proxies from the perspective of "who chooses the stand-in," and give one representative use of each.

Exercise 2. What is the fundamental weakness of a single proxy, and with what structure does Tor solve it? After the solution, what do the guard node and the exit node each know?

Exercise 3. Plaintext HTTP is dangerous even with Tor. On which stretch is the content exposed, and to whom?

Exercise 4. Most "used Tor but got caught" cases are not broken encryption. Give two or more non-technical paths by which identity is revealed.

5. Model Answers & Completion Criteria

Mission Model Answer

#2: the table’s key cells are the exit-node row — destination "knows," plaintext content "knows," my IP "doesn’t know." And it’s easy to miss, in the ISP row, that "the fact that I use Tor is itself visible." Tor use is a matter of metadata, not content, and that connects exactly to Step 85’s lesson (encryption hides only the content).

Sample answer for #3: ① Check whether each IP is on the public Tor exit list, and if so, assume it’s merely the "final hop." ② Bundle by commonalities of time window, target account, and request pattern to see if it’s "one attacker’s sessions" (behavioral fingerprint). ③ Since clues before the exit can’t be obtained directly, pivot to defense — enforce additional authentication (MFA) on the account and notify. When tracing fails, moving to blocking and detection is the practical order.

Sample criterion for #4: as we saw in 3-1, a free proxy can see all of a plaintext request, so never use it for communications carrying logins, personal data, or payments. Conversely, for "content that may be read" like simple viewing of public pages, the risk is managed. The judgment criterion is one line — would it still be okay if this proxy read everything?

How to verify: ① Does each structure diagram state "who knows what"? ② Did you accurately mark the exit node’s plaintext exposure in the table? ③ Does the scenario answer go beyond "untraceable" to the defensive pivot? ④ Is the proxy judgment criterion grounded in Step 132’s measured log?

Exercise Answers

Answer 1. The stand-in the client chooses is a forward proxy (uses: hiding my IP, network bypass, traffic inspection); the stand-in the server chooses is a reverse proxy (uses: load balancing, server concealment, TLS termination). Remember the direction of the names as "in front of whom they stand."

Answer 2. A single proxy knows both me and the destination, so anonymity collapses with that one proxy’s logs (or cooperation). Tor splits the stand-in into three so no single one sees the whole picture. The guard node knows my IP and not the destination; the exit node knows the destination and not my IP. The middle node knows neither.

Answer 3. The stretch from the exit node to the destination server is the regular internet, so if that stretch is plaintext, the exit-node operator (and anyone eavesdropping on that stretch) can read the content. Regardless of the encryption inside Tor, the last stretch outside the exit needs separate protection (HTTPS).

Answer 4. ① The behavioral mistake of logging into a usual account while connected anonymously, ② browser fingerprinting (the unique setting combination of one’s usual browser), ③ timing correlation analysis at both entry and exit, ④ leaks where malware or plugins bypass Tor and connect directly. The common thread: what collapsed was not the onion encryption but everything outside it.

Completion Criteria Checklist

[ ] I can distinguish forward/reverse proxies by "who chooses"
[ ] I can explain, with Step 132’s measurement, that a proxy sees every request in exchange for hiding your IP
[ ] I can explain the difference between HTTP and SOCKS proxies
[ ] I can draw a table of what Tor’s guard/middle/exit nodes each know
[ ] I can explain why plaintext HTTP + Tor is dangerous
[ ] I can name three or more non-technical factors that break anonymity
[ ] I can compare direct connection, VPN, and Tor by "who knows what"

6. Common Pitfalls & Fixes

Wall 1. "Isn’t using a proxy completely safe?"

Symptom: you pick one from a free proxy list and try to reach your bank’s site.
Cause: you’re confusing "the server doesn’t know me" with "no one knows me." The proxy operator sees your IP and every request — 3-1’s log is the evidence.
Fix: send only "traffic that may be read" through proxies you can’t trust. Communications involving logins or payments must go only through exits you trust (your own VPN, your company’s official proxy).

Wall 2. "I connected to a free proxy and nothing works"

Symptom: proxychains repeats timeouts.
Cause: a large share of free proxy lists are dead, or alive but traps (malicious proxies that read or alter content).
Fix: try several, but remember that the process itself is the lesson — this is exactly the reliability of a "free stand-in," one of today’s limits. For learning purposes, a local proxy you built yourself (Step 132) is a better teacher.

Wall 3. "I turned on Tor and it’s incredibly slow"

Symptom: pages load several times slower.
Cause: that’s normal. Traffic crosses three volunteer relays and circles the globe. Latency is the price of anonymity.
Fix: it’s not a problem to fix. The answer is separating tasks that need speed from tasks that need anonymity.

Wall 4. "I installed extensions in the Tor Browser"

Symptom: you add your usual extensions for convenience.
Cause: extensions break the Tor Browser’s careful defaults (fingerprint resistance), and identity can leak through the extension’s own traffic.
Fix: use the Tor Browser exactly as received. "The moment you change the settings, it becomes your own fingerprint" is the core principle of fingerprinting.

Wall 5. "Isn’t a longer chain unconditionally safer?"

Symptom: chaining seven proxies seems perfect.
Cause: more links make tracing harder, but you must trust every link, and latency accumulates. And the weakest link — usually the last exit or your own behavioral habits — determines the whole strength.
Fix: evaluate not by "count" but by "who runs each link" and "is there anywhere my habits leak?" The reason Tor’s three became the settled answer is the balance of strength and delay.

Wall 6. "Wouldn’t VPN plus Tor be perfect?"

Symptom: you want to layer every anonymity tool.
Cause: layering only changes the picture an observer sees — it never becomes zero. With Tor over VPN, the VPN company (instead of the ISP) learns "this user uses Tor," and the latency of two tools stacks.
Fix: change the question before combining — not "what else should I layer" but "which observer do I want to block." Find that observer’s row in 3-6’s table and pick the one layer you need; that’s the textbook approach. Layering is not a hobby — it’s the answer to a threat model.

7. Summary

Today’s Concepts

Concept	One-line explanation
Forward proxy	The client’s stand-in — hides my IP from the server; in exchange the proxy sees everything
Reverse proxy	The server’s stand-in — hides the real server behind it and answers out front
HTTP / SOCKS proxy	Relays only the web / relays any TCP
Proxy chain	Stringing several stand-ins to scatter the logs needed for tracing
proxychains	A tool that assembles the chain in the order of its config file
Tor	Guard-middle-exit triple relay — so no node knows the whole
Onion routing	Encrypted in as many layers as there are nodes — each peels only its own skin
Exit node	The last link, able to see the destination and plaintext content
Fingerprinting	The fingerprint made by a browser’s setting combination — identifies without an IP
Timing analysis	Tracing by pairing flows observed at both entry and exit
VPN	Encrypts all of a device’s traffic to an exit server — the choice of concentrating trust in one company
Threat model	The question "whose observation am I blocking?" — the starting point of tool choice

Today’s Tools & Commands

Item	What it does
Step 132 mini proxy	The tool that measured "a proxy sees everything" firsthand
`/etc/proxychains.conf`	The config file where the proxy chain order is written
`proxychains <command>`	Send an arbitrary program’s traffic through the chain
Tor Browser	The dedicated browser with triple relay + fingerprint resistance as defaults
Browser dev tools (F12)	Observe response headers and request flows — also used to confirm proxy behavior

An Instinct More Important Than Commands

Today’s summary is one sentence. Anonymity is not given by the tool — it’s the multiplication of tool and habit. Log into your usual account on top of the world’s best onion routing, and one factor of the multiplication becomes zero. Conversely, for the defender, hope sits in the same place — you may not break the encryption, but the attacker’s habits leak.

And remember the law of stand-ins: a stand-in sees you in exchange for standing in for you. If you can recall 3-1’s log when you wonder what you’re giving up behind the convenience of one free proxy line, today’s goal is achieved.

Finally, today’s structures don’t belong only to those who hide. Guarding a server with a reverse proxy, reading an exit IP in the logs to find a thread for tracing, setting the direction of an incident investigation with the fact that "anonymity is multiplication" — all are different readings of the same map. That attack and defense share one map — this whole unit’s theme — is present intact in today’s chapter.

Once every box is checked, Step 162 is complete. Click the checkbox in the sidebar to save your progress.