Tor: The Second-Generation Onion Router

1. Tor: The Second-Generation Onion Router Roger Dingledine, Nick Mathewson, Paul Syverson The Free Haven Project &Naval Research Lab Presented by: Corey White

2. Table of Contents • Background Information • Tor Enhancements over Original • Related Work • Design Goals and Assumptions • The Tor Design • Rendezvous Point and hidden Services • Design Decisions • Attack and Defenses • Early experience: Tor in the Wild • Open Questions in Low-Latency Anonymity • Future Direction • Conclusion

3. 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.

4. 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.

5. Background Information http://en.wikipedia.org/wiki/File:Onion_diagram.svg

6. 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

7. Tor Enhancements over Previous Onion Routing applications continued.. • Directory servers • Previous designs resorted to flooding info on the network. • Variable exit policies • End-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.

8. 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.

9. 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 responses • Freedom • 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.

10. 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.

11. 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

12. 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.

13. 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.)

14. 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.

15. 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

16. Tor Design continued.. Alice builds a two-hop circuit and begins fetching a web page. https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.html

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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.

32. 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.

33. 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.

34. 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.

35. 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

36. 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.