Breaking Tor on a Budget

This page is a 2026 reanalysis of CVE-2014-5117, the “relay early” traffic confirmation vulnerability in Tor. The original work that led to the CVE was performed at Carnegie Mellon SEI/CERT in 2014, but the underlying research notes were never released publicly. Everything written here is a fresh look at the disclosed vulnerability class, not a reproduction or release of any prior 2014 material.

The vulnerability was responsibly disclosed and patched in Tor 0.2.4.23 on July 30, 2014. The specific signaling channel demonstrated in the interactive lab below is no longer present in modern Tor; an inbound RELAY_EARLY cell now tears down the circuit on receipt. The lab is preserved as a teaching artifact for the reasoning that breaks anonymity systems, not as a working recipe against today’s network.

Background

Onion routing in one paragraph

Tor’s anonymity property comes from sending each client connection through a three-relay circuit: an entry guard, a middle relay, and an exit. Each relay sees only its immediate neighbors and decrypts exactly one layer of encryption per hop. The entry guard learns the client’s IP but never the destination; the exit learns the destination but never the client; the middle is a pure pass-through. No single honest relay knows the whole path. Hidden-service circuits extend the same idea with an introduction point and a rendezvous point so neither the client nor the service learns the other’s IP.

Fixed-length cells

Every traffic unit on a Tor circuit is a fixed-length cell: 514 bytes in the current link protocol, 512 in earlier ones. The uniform size is a deliberate security primitive rather than a wire-format convenience. There is no per-cell length field to misparse, no variable-length payload to overrun on the read path, no per-cell size fingerprint for a network observer, and the work each relay performs per message is bounded by the cell size. A meaningful share of Tor’s robustness against memory-corruption attacks comes from this single design choice.

What was reviewed and held up

The 2014 effort began as a broader security review of the Tor software and protocol, originally undertaken as a student project. The protocol-layer flaw only emerged after several more enticing layers were exercised and ruled out:

• Cryptography. The ntor handshake, link-layer TLS, and per-hop AES were not the weak link.
• Network and consensus design. Vote signing, descriptor handling, directory authority integrity, and circuit construction held up under code review.
• Memory safety. Fuzzing the C reference relay produced no actionable findings. The fixed-cell-size design and tight buffer management closed off most of the obvious memory-corruption surface, and what remained did not yield a usable bug.

With the usual suspects ruled out, the remaining attack surface was the protocol logic itself: the rules a relay applies when forwarding, transforming, or rejecting a cell. That is where the RELAY_EARLY deterministic signaling channel lived.

The deterministic signaling channel

Unlike many previous Tor security findings, this was not a probabilistic method, but a deterministic one. It relied on a combination of protocol and software weaknesses. The mechanism is traffic confirmation. A small set of malicious relays tag traffic at one end of the circuit by manipulating Tor cell headers in ways the client cannot see, and recognize the same tag at the other end. The result is high-confidence correlation between the entry-side and the exit-side observation of the same circuit, with no ciphertext attack and no probabilistic statistical analysis, just a bit-for-bit match. The circuit-based anonymity guarantee assumed relay honesty in a place where it should not have.

The lesson for fledging security researchers is to challenge assumptions: Don’t believe what you are told, and look where you are told there is nothing to find.

How RELAY_EARLY became bidirectional

RELAY_EARLY is not a poorly conceived cell type. It was added to Tor to cap a circuit-extension attack: a relay forwards a RELAY_EXTEND cell only when it arrives wrapped as RELAY_EARLY, and a hard per-circuit limit (originally 8) on the number of RELAY_EARLY cells bounds how far an adversary can grow a circuit. The cell type carries a directional invariant. RELAY_EARLY cells are specified to flow strictly outbound, from the client toward the far end of the circuit, and never the other way.

The break came with hidden services. A client circuit and a service circuit are stitched together at a rendezvous point to form one logical end-to-end circuit, and the way that stitching is done means RELAY_EARLY cells that were legitimate on one half could legitimately arrive in the inbound direction at the other half’s endpoints. Early relay implementations enforced the spec’s directional invariant and dropped those inbound RELAY_EARLY cells. That broke hidden-service rendezvous. The pragmatic fix shipped in the implementation was to quietly accept inbound RELAY_EARLY cells and process them the same way as ordinary RELAY cells.

The change kept hidden services working. It also created a one-bit-per-cell side channel that nothing in the rest of the system was watching for. An adversarial relay anywhere on the inbound path could flip an outgoing RELAY cell into a RELAY_EARLY cell, and no downstream relay or the client itself would notice, reject, or log the substitution. The cell-type field, designed as a directional invariant, had quietly become a writable bit on the return trip.

This is the kind of bug a spec review will not find. The Tor specification still described RELAY_EARLY as outbound-only with a per-circuit cap. The bug lived in the gap between the spec and the C reference relay, in a change that loosened an invariant to fix an unrelated correctness problem. Catching it required reading both and noticing where one no longer matched the other.

The lab below walks the attack lifecycle: circuit layering, the deterministic signaling step itself, the formal probability of compromise, and the Sybil scaling that made a $3,000-per-month attacker plausible at 2014 network sizes. If you have not thought about onion routing at the cell level before, start at section zero.

What changed since 2014

The Tor Project shipped serious mitigations in the years following this disclosure, and the picture today is meaningfully better than what the lab simulates. Three of the most important shifts:

• Hidden services v3. The protocol that ran during this research (v2) leaked the hidden-service identity to the directory tier: HSDir relays could see which .onion was being looked up, which is exactly what made the Sybil-on-HSDir variant so cheap. v3 (now the default) uses cryptographic blinding and shared randomness so directory and intro-point relays no longer see the underlying service identity. They handle requests they can’t index. The class of attacks that depended on enumerating unknown onions at HSDir is closed. v3 does not, however, close targeted surveillance of a .onion an adversary already knows: the blinded descriptor ID is deterministic given the address and the current time period, so a Sybil HSDir can still confirm activity and watch lookups for any specific service whose address it possesses.
• Entry guard policy. Tor now uses a single primary entry guard by default, falling back to a second or third only if the primary is unreachable, and the rotation period was extended to roughly four months. This collapses the guard surface a Sybil adversary can occupy and shrinks each client’s lifetime probability of ever landing on a malicious guard.
• Signaling hygiene at the cell layer. Tor’s protocol team added defenses against the kind of header-mutation games used in this attack: tighter cell validation and stricter handling of unexpected RELAY_EARLY cells, including tearing down circuits that carry RELAY_EARLY cells in the inbound (toward-client) direction. Deterministic signaling in the form used here would not survive a modern relay. Residual protocol weaknesses almost certainly remain; for an updated review against the current Tor codebase, reach out at michael@mccord.ai.

Traffic correlation by an adversary with end-to-end visibility is still the dominant theoretical risk for low-latency mixnets, and the relay ecosystem still has to assume some operators are adversarial. The lab is preserved as a teaching artifact for the reasoning that breaks anonymity systems, not as a recipe that works against today’s network.

Lessons learned

After finishing this reanalysis I put the obvious question to a handful of frontier LLMs: handed a checkout of Tor at a version vulnerable to CVE-2014-5117 and a security-review prompt, would any of them surface the RELAY_EARLY channel unprompted? The results were mixed. Some models recalled the CVE directly when I asked them about Tor vulnerabilities of that era, which is unsurprising since the disclosure is public and was almost certainly in their training corpus. Others recognized the CVE when named, but did not surface the signaling channel during a source-level review of the vulnerable code.

The contamination is hard to factor out. When a model “finds” a known CVE in a known codebase, it is difficult to tell whether it is reasoning forward from the code or pattern-matching backward from its training data. That makes any confident claim about agent capability on this specific bug premature.

Stepping back from the specific CVE, the structural question is whether modern agents reliably surface this class of bug, where the discovery requires holding the protocol specification and the implementation in mind at the same time, noticing where one no longer matches the other, and composing that local finding with a Sybil-scaling argument to get to a network-level impact. The individual steps (read a spec, read code, spot a deviation, generalize an attacker model, estimate a budget) are within reach of current systems. The integration step is the one that does not show up cleanly in any benchmark I trust. My honest read is that this class of vulnerability sits at the edge of what current LLM-driven security review can find unaided, and the edge is moving. I would be cautious about assuming we are not already at the point where a discovery like this could be made by an AI agent on its own.

There is a complementary data point from preparing this writeup itself. I used Opus 4.7, GPT 5.5, and Gemini 3 to help with the design and content of this 2026 review, including the interactive lab. Even with the vulnerability details and the disclosure history fully laid out as context, the models made many small but consequential mistakes interpreting how the channel works, how it actually affects the Tor network, and how the Sybil math composes. The lab and the surrounding prose required substantial correction before they aligned with the disclosed vulnerability and its real impact. Generative AI is a genuinely useful tool for this kind of work; it is not a replacement for purposeful security research.

The actionable takeaway for anyone considering responsible security research against anonymity networks today is that LLM assistance is worth treating as a real, recommended tool. It is not a replacement for protocol-first reasoning; it is a force multiplier for it. A careful human reviewer paired with an agent that can navigate code, recall protocol context, and surface candidate inconsistencies is a healthy direction for disclosure work against Tor and systems like it, and the residual weaknesses in those systems are the right target.

References

The mitigations described above are drawn from the Tor Project’s own advisories and specifications:

• CVE-2014-5117 disclosure and the RELAY_EARLY fix: Tor security advisory: “relay early” traffic confirmation attack, The Tor Project (July 30, 2014). Documents the original attack and the 0.2.4.23 / 0.2.5.6-alpha protocol fix.
• Hidden services v3: Proposal 224: Next-Generation Hidden Services in Tor and the current Tor Rendezvous Specification, Version 3.
• Entry guard policy: Proposal 271: Another algorithm for guard selection and the current Tor Guard Specification.