Roger Dingledine, Nick Mathewson, Paul Syverson

The Free Haven Project &Naval Research Lab

Presented by: Corey White

Tor: The Second-Generation Onion Router

Table of Contents

Background InformationTor Enhancements over OriginalRelated WorkDesign Goals and AssumptionsThe Tor DesignRendezvous Point and hidden ServicesDesign DecisionsAttack and DefensesEarly experience: Tor in the WildOpen Questions in Low-Latency AnonymityFuture Direction Conclusion

Background Information

What is an Onion Routing (Original)?

Onion routing is an anonymous communication technique over a computer network. Messages are constantly encrypted and then sent through several network nodes called onion routers which creates a circuit of nodes.

Each onion router removes a layer of encryption with its symmetric key to reveal routing instructions, and sends the message to the next router where this is process is repeated.

Thus the analogy “onion router”. This prevents these intermediary nodes from knowing the origin, destination, and contents of the message.

Background Information continued..

What is Tor Onion Routing?: Second Generation Onion Routing

Tor is a distributed overlay network which anonymizes TCP-based applications (e.g. web browsing, secure shell, instant messaging applications.)

Clients choose the circuit paths Message are put in cells and unwrapped at each node

or onion router with a symmetric key. The ORs only know the successor or predecessor but

not any other Onion Router.

Background Information

http://en.wikipedia.org/wiki/File:Onion_diagram.svg

Tor Enhancements over Previous Onion Routing applications

Tor uses telescoping path-built design Previous designs allowed hostiles to record traffic and

compromise successive nodes. Tor uses SOCKS proxy interface

Previous designs required a separate application proxy for each application protocol.

Tor is able to share one circuit for many TCP streams Previous designs required a separate circuit for each

application level request. Which is a threat to anonymity.Leaky pipe circuit topology

Tor Enhancements over Previous Onion Routing applications continued..

Directory servers Previous designs resorted to flooding info on the

network.Variable exit policiesEnd-to-end integrity checks

Previous designs had no integrity checks.Rendezvous points/hidden services

Previous designs included replay onions.Congestion control: uses end-to-end acks

Previous designs didn’t address traffic bottlenecks.

Related Work

Chaum’s Mix-Net design Correspondence hiding between sender & receiver by

wrapping messages in layers and relaying through “mix” routers.

Babel ‘s Mix master and Mixminion Try to maximize anonymity at the cost of high latency.

Anonymizer Single-hop proxy

PipeNet Low-latency design giving user anonymity by shutting

down the network by not sending.

Related Work

P2P Tarzan and MorphMix designs Rely and generate traffic for other participating users and

hide who originated or relayed a request.Hordes/Crowds

Hides the initiator of traffic thorough multicast responsesFreedom

Supports session keys and address of the server in a circuit.

Rennhard’s Anonymity Network Builds circuits in stages which helps to obtain perfect

forward secrecy by extending them one hop at a time.

Design Goals and Assumptions

Main Goals: Disrupt attackers from linking communication partners, or from linking multiple communications to or from a single user.

Sub Goals: Deployability: must be inexpensive to implement (e.g.

requiring kernel patches), can’t require non-anonymous parties like websites to run the software.

Usability: a security requirement to hide users among users which should not require modification of applications, no prohibitive delays, and few configuration decisions, and easy implementation on all common OS platforms.

Design Goals and Assumptions continued..

Sub Goals: Flexibility: the protocol should be flexible and well

specified for future research work. Simple design: the protocols design and security must be

user friendly.Non Goals or Weaknesses

No peer to peer environments Unsecure against end-to-end attacks No protocol normalization-Tor must be layered with

filtering proxy when using variable protocols like HTTP. No steganographic-Tor doesn’t conceal who is connected

on the network

Design Goals and Assumptions continued..

Thread Model Passive adversaries are the most common threats They can also launch active attacks by compromising

keys and or routers, deny service to trustworthy routers to force users toward compromised routers, or deny service to users to see if other traffic stops.

Adversaries also can subvert directory servers and decrease node reliability by attacking nodes or by performing antisocial activity from reliable nodes in order to take them down.

Tor aims to prevent traffic analysis attacks, where the adversary uses traffic patterns to learn which points of the network to attack.

Tor Design

Tor is an overlay network Each router has a user-level process w/o special privileges.

Each onion router maintains a TLS connection to every other onion router.

Each user runs local software called onion proxy (OP) to fetch directories, establish circuits across the network, and handle connections from users.

Each router maintains a long-term & short term onion identity key. These are used to sign TLS certificates which sign the OR’s router descriptor(summary of keys, address, bandwidth ,etc.)

Tor Design continued..

Cells Traffic passes along the connections in fixed-sized cells

which are 512 bytes with a header and a payload. Cells consists of a header(circuit identifier or circID) to

determine which circuit the cell refers to. Also a command to describe what to do about the cell’s payload.

Cells are either control cells: always interpreted by the nodes that receive them or…

relay cells: which carry end-to-end stream data. Also relay cells have an additional header on front of the payload containing a streamID, integrity checksum, length of payload and relay command.

Tor Design continued..

Relay Commands Relay data: data flowing down stream Relay begin: to open a stream Relay end: to close a stream cleanly Relay teardown: to close a broken stream Relay connected: to notify successful relay begin Relay extend/extended: to extend the circuit by a hop Relay send me: congestion control Relay drop: implements long-range dummies

Tor Design continued..

https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.html

Alice builds a two-hop circuit and begins fetching a web page.

Tor Design continued..

Relay Cells Once a connection is established a user can send relay

cells (relay truncated, destroy, create cells)

OR receive relay cells, look up the corresponding circuit and decrypts the relay header and payload with the session key for the circuit. Also checks for a valid digest for outgoing cells.

If not valid, the OR finds the circID for the next step in the circuit, replaces the appropriate circID, and sends the decrypted relay cell to the next OR.

Tor Design continued..

Opening and Closing Streams A user like Alice can obtain a TCP connection via SOCKS The OP chooses a new open circuit and suitable OR to be

an exit node The OP then sends a relay begin cell to host, the host

responds with relay connected cell. The SOCKS relays to notify its success. The OP now accepts data from the TCP stream, which is

packaged into relay data cells and passes these to the intended OR.

SOCKS’s weakness is revealing of user destinations if the intended application does DNS resolution first.

Tor Design continued..

Integrity Checking on Streams Integrity checks are only done at the edges of each

stream(leaky-pipe circuit topology allows a streams edge to be any hop in the circuit)

The OP and the hop initialize a SHA-1 digest with a derivative of the key, then both add to the digest the contents of all relay cells they create.

Each side also keeps a SHA-1 digest of data received , to verify correctness of the hashes.

A cell has four bytes to lower overhead, which leaves an adversary’ chances of guessing a valid hash to very low, also the OP or OR tear down the circuit if they get a bad hash.

Tor Design continued..

Rate limiting and fairness Tor uses a token bucket approach to enforce long-

term average rate of incoming bytes, while still allowing short-term bursts above the allowed bandwidth to limit bandwidth usage.

Tor provides good latency for interactive streams and good overall throughput to the bulk streams by acting as if the entire cell has been read disregarding the cell’s fullness. The local application may be waiting for a reply and this method accomadates this position without waiting for more bytes.

Tor Design continued..

Congestion Control (circuit-level throttling) Each OR keeps track of two windows, the packaging window:

tracks how many relay data cells allowed to the OR for packaging back to the OP. The delivery window: tracks how many relay data cells given to TCP streams outside the network.

OR after receiving enough data cells, it sends a send me relay to the OP with streamID zero. It then increments the packaging window by 100. If the window reaches 0 the OR stops reading from TCP connections for all streams on the corresponding circuit, and stops until another send me relay is received

Congestion Control (Stream-level throttling) Similar to circuit level throttling but checks for successful

flushed TCP stream, and only sends “send me” relays when flushed under a set threshold by the user.

Rendezvous Points and Hidden Services

Rendezvous points are building blocks for location-hidden services(responder anonymity)

It allows an OP to offer a TCP service without revealing his IP address. This protects against DoS attacks.

Goal for location hidden servers Access-control: filters incoming requests to prevent

flooding Robustness: Users maintains a long-term pseudonymous

identity even during failure Smear-resistance: frame prevention on rendezvous routers Application transparency: no modification of user special

software.

Rendezvous Points continued..

Rendezvous Points in Tor User 1 generates a long-term public key pair to identify his service. User 1 chooses some introduction points, and advertises them on the

lookup service, signing the advertisement with his public key. User 1 builds a circuit to each of his introduction points, and tells them to

wait for requests. User 2 learns about User 1 ’s service out of band (perhaps via lookup

service If user 2 wants to access User 1 ’s service anonymously, she must connect via Tor to the lookup serivce.

User 2 chooses an OR as the rendezvous point for her connection to user 1’s service. She builds a circuit to the RP, and gives it a randomly chosen “rendezvous cookie” to recognize user 1.

User 2 opens an anonymous stream to one of user 1’s introduction points, and gives it a message (encrypted with User 1’s public key) telling the RP and rendezvous cookie, and the start of a DH handshake. The introduction point then sends the message to user 1.

Rendezvous Points continued..

If User 1 wants to talk to user 2 he builds a circuit to user 2’s RP and sends the rendezvous cookie, the second of half of the DH handshake, and a hash of the session key they now share. By the same argument, this enables user 2 of knowing she shares the key only with user 1.

The RP connects user 2’s circuit to user 1’s. at this point the RP can’t recognize user 2, user 1, or the data they transmit.

User 2 sends a relay begin cell along the circuit. It arrives at user 1’s OP, which connects to user 1’s web server.

An anonymous stream has been established, and user 2 and user 1 can now communicate as normal.

Other Design Decisions

DoS and Tor Tor is vulnerable to DoS attacks because users can

consume more network resources than allowed or render the network unusable for other users.

Tor deals with these attacks with Puzzle solving: done at the beginning of a TLS

handshake or accepting create cells, this limits the attack multiplier.

Limiting rates: this limits the rates of accepting of create cell and TLS connections so the computational work of processing them doesn’t disrupt the symmetric cryptography operations that allow cells to flow.

Other Design Decisions continued..

Exit Policies and Abuse: Tor deals with abuse thorough its abuse policy including.. Exit Policy: tells which external addresses and ports

will connect to where. Open exit nodes: connect anywhere Middleman nodes: only relay traffic to other Tor

nodes. Private exit nodes: allows a client to connect more

securely to a host. This prevents eavesdropping.

Other Design Decisions continued..

Directory Servers Tor uses small group of onion routers to track changes in

network topology and node state, including keys and exit policies.

These directory servers act as HTTP servers that fetch state and router lists, and allows for other ORs to upload state information.

The directory servers combine this info with their own network liveliness and generate the signed description or directory of the entire network.

All new nodes must be approved by the directory servers and their keys to prevent attackers from taking over the network by creating many servers.

Attacks and Defense

Passive Attacks Observing traffic patterns: Observance of user traffic will

not reveal destinations or date, but reveals patterns of sent and received data.

Observing user content: Tor uses Privoxy and related filtering service to anonymize application data streams.

Optional distinguishability: allows for clients to choose configuration options but is a threat to anonymity.

End-to-end timing correlation: hides the connection between the onion proxy and the first Tor node, this runs the OP on the Tor node and or behind the firewall.

Attacks and Defense

End-to-end size correlation: simple packet counting is effective attack which confirms endpoints of a stream.

Website fingerprinting: Is a database of patterns of file sizes and access patterns for targeted websites. This is less effective against Tor because it’s streams are multiplex within the same circuit.

Attacks and Defense

Active Attacks Compromise keys: Compromised session keys that

leave control cells and encrypted cells on every circuit on the connection vulnerable.

Iterated compromise: This is compromising of the ORs, this is hindered because session keys are forward in secrecy, which won’t allow nodes to decrypt recorded traffic once the circuit is closed.

Run a recipient: an adversary learns the timing patterns of connecting users and introduces arbitrary patterns in its response.

Attacks and Defense

Onion Proxy: compromising of onion proxies compromises all future connections through it.

Tagging attacks: hostile nodes tag a cell by altering, but integrity checks on cells prevent this attack

Replay attacks: Tor is not vulnerable to replay attacks because of protocols of session keys during a handshake.

Smear attack: Exit policies deter the abusive socially unacceptable acts on the network.

Distribute hostile code: tricks users into running subverted Tor software that reduces their anonymity.

Attacks and Defense

Directory Attacks Destroying directory servers: few destroyed directories

won’t effect the network, but half destroyed is harmful because it doesn’t have enough to display a view of the network and give a consensus directory.

Subvert a directory server: compromising a directory server an attacker can influence the view of the final directory.

Subvert a majority of directory servers: allows for compromising of ORs in the final directory

Trick the directory servers into listing a hostile OR: This is deterred by Tor’s directory server operators filtering out hostile ORs.

Early Experiences: Tor in the Wild

Tor network Tor as of May 2004, has 32 nodes( 24 in the US , 8 in

Europe) Each node has 768/768 connection and many have 10

Mb. Each node processed 800,000 relay cells per week Tor has been used for web browsing, FTP, IRC, Kazaa,

etc. Latency attributed to two factors: bouncing of traffic

around the world several times and end-to-end congestion which protects users from DoS.

Open Questions in Low-Latency Anonymity

How often should users rotate to fresh circuit?: Frequent rotation is expensive and inefficient and could

lead to attacks, while infrequent rotation make the user’s traffic linkable.

How to choose path lengths?: using two hops per user could disrupt anonymity

because of the timing pattern it could create.How to disrupt end-to-end confirmation?:

affects both high and low latency systems. Tor uses long-range wrapping of control commands in similar looking relay cells to reduce to chance of this attack.

Future Directions

Tor wants to improve on Scalability Bandwidth classes: advertisement of bandwidth levels Incentives: rewards including publicity and better anonymity Cashing at exit nodes: running a cache proxy Better directory distribution: distribute up-to-date network

snapshots Further specification review: more external review of Tor Multisystem interoperability: allow more testing design

comparisons Wider-scale deployment: more users for better design

evaluation

Conclusion

Tor is great with providing anonymity ,deterring replay attacks and ensuring integrity checks. It is very versatile allowing web- browsing FTP, IRC, AIM, Kazaa, SSH, and recipient-anonymous email via rendezvous points.

Unfortunately its vulnerabilities to several passive and active attacks within its network at critical areas leave it in need of vast improvements and research in the future.