The Second-Generation Onion Router R. Dingledine, N. Mathewson, P. Syverson Presented By: Enrico Chandler Maryam Jafari-Lafti

Presentation Outline What is anonymity? Modern Anonymity Systems The original Onion Routing Tor’s goals and improvements Tor implementation Threat Model Tor in the wild Future directions Conclusions

What is Anonymity? Anonymity can be defined as maintaining (real-world) identifying information about a transaction and/or the communicating parties hidden Why do we need anonymity? Protecting “sensitive” activities, censorship resistant publishing, protecting against profiling, whistleblowing, etc. Common types of anonymity: sender anonymity, receiver anonymity, unlinkability of the sender and receiver, unlinkability of transactions Various levels of anonymity (application and/or network layer) Merriam-Webster Online Dictionary

Anonymity or Pseudonymity? Anonymity vs. Pseudonymity Full anonymity conflicts with accountability Pseudonymity allows for authentication and establishment of trust Actions could be linked back to a pseudonym (virtual identity) but most often not to the real-world identity Merriam-Webster Online Dictionary

Modern Anonymity Systems Date back to Chaum’s Mix-Net design Suggested hiding correspondence between sender and receiver by wrapping messages in layers of public key encryption These messages would traverse a series of mixes en route to the receiver Mixes decrypt, delay, and re-order messages before passing them onward

Basic Mix-Net Concept* Server 1 Server 2 Server 3 m1 m1 m3 m2 m2 m3 m1 m2 m1 m3 Decrypt & Permute Decrypt & Permute Decrypt & Permute m2 m3 Ciphertext = EPK1[EPK2[EPK3[m]]]

Relay Based Systems High Latency Low Latency Babel, Mixmaster, Mixminion Maximizes anonymity and the cost of large latencies Networks resist strong global adversaries Introduces too much lag for some TCP applications Low Latency Tor, Anonymizer, Pipenet Attempt to anonymize interactive traffic which contain more packets that are time dependent Handles a variety of bidirectional protocols Time dependency of communications is a design concern

The Original Onion Routing Distributed overlay network to anonymize TCP-based applications Client-side Onion Proxy (OP) chooses circuit of onion routers An Onion Router (OR) is a server which receives messages from end nodes, batches and reorders them, and forwards them towards the destination Messages are broken into fixed size cells and packaged into a data object called the “onion” via successive layers of encryption As the onion traverses the circuit, the encryption layers are “peeled” off and the message is passed down to the next OR in the circuit

The Original Onion Routing*

Onion Routing Deployment Deployed briefly Fragile proof of concept on a single machine Processed connections from over 60,000 IPs Many critical design and deployment issues never resolved Tor incorporates improvements over old onion routing

Tor Design Goals & Non-Goals Deployability Usability Flexibility Simple Design Non-Goals Not peer-to-peer Not secure against end-to-end attacks No protocol normalization Not designed to prevent traffic confirmation attacks Design is aimed to prevent traffic analysis attacks

Deployment & Usability Must be deployed and used in the real world Not expensive to run Not place a heavy burden on operators Must not be difficult or expensive to implement Can’t require non-anonymous parties to run software Usability Hard to use system equal fewer users which provides less anonymity Should not require to modify familiar applications Easily implementable on all platforms

Flexibility and Simple Design Must be flexible to serve as a test bed for future research Design and security parameter must be well understood Aim to deploy a simple and stable system that integrates the best accepted approaches to protecting anonymity

Tor Improvements Perfect forward secrecy Separation of “protocol cleaning” from anonymity Many TCP streams can share one circuit Leaky-pipe circuit topology Congestion control Directory servers Variable exit policies End-to-end integrity checking Rendezvous points and hidden services

Improvements Perfect forward secrecy Original routing allowed recording of traffic Tor uses incremental or telescoping path-building design Onion replay detection is no longer necessary Protocol cleaning from anonymity Original routing required separate application proxy Tor uses standard SOCKS proxy

Improvements Many TCP streams Original routing built separate circuits Multiple key operations Threats to anonymity Tor multiplexes multiple TCP streams Leaky-pipe circuit topology Tor initiators can direct traffic to nodes partway down circuit This can possibly frustrate traffic shape and volume based on observing the end of circuit

Improvements Congestion control Earlier anonymity designs do not address Tor decentralizes congestion control with end-to-end ACKs This maintain anonymity while allowing edge nodes to detect congestion or flooding Directory servers Original routing planned to flood state information through the network Tor uses trusted nodes that act as directory servers to provide network state

Improvements Variable exit policies Tor provides a mechanism for nodes to advertise host and ports to which it will connect End-to-end integrity checking Original routing did no integrity checking Tor verifies data integrity before it leaves the network

Improvements Rendezvous points and hidden services Original routing provided long lived reply onions Did not provide forward security Became useless if any node went down or rotated its key Tor clients negotiate rendezvous points to connect to hidden servers No reply onions are required

Tor’s Design OR 1 OR 3 OR 2 OP Server Circuit

Onion Routers & Proxies Onion routers connect to destinations and relay user data Onion router keys: Identity key: long-term, signs TLS certificates, OR router descriptors, and directories if applicable Onion key: Used with circuit establishment requests TLS key: short-term, link level between ORs Client-side OP is responsible for: Fetching OR directories Establishing circuits Handling connections from applications

Circuits & Streams Circuits & Streams A circuit is a set of intermediaries (ORs) for traffic indirection One circuit for multiple TCP streams Periodic background circuit set-up and expiration Circuits built in increments (one hop at a time) Question: What are the pros and cons of several cryptographic layers?

Cells Control cells: Always interpreted, contains circID Possible commands are: padding, create, destroy Relay cells: Include additional header, used to control various aspects of stream set-up and data transmission Possible commands are: relay data, relay begin, relay end, relay teardown, relay connected, relay extend & extended, relay truncate & truncated, relay sendme, and relay drop

Opening & Closing Circuits Circuits are built preemptively and periodically to avoid delays and limit linkability Circuits are build incrementally, negotiating a symmetric key with each OR in the circuit one hop at a time Circuits can be closed incrementally by sending a relay truncate cell to a single OR and having it pass forward a relay destroy cell Truncated circuits can be re-extended Question: How can the circuit building/closing processes be exploited by malicious ORs? Question: How long should circuits be? Fixed length or dynamic length?

Opening & Closing a Circuit Alice builds a two-hop circuit Alice OR 1 OR 2 Relay c1{Truncate} Relay c2{Destroy} Relay c1{Truncated} Alice truncates its circuit to include only OR 1

Leaky Pipe Circuits The leaky pipe circuit topology allows client streams to exit at different ORs on a single circuit The client may select different exit points based on their exit policies or to reduce linkability OR 1 OR 3 (exit) OR 2 (exit) OP Server Server

Opening and Closing Streams Given that the OP has a set of open circuits and it receives an application request for a TCP connection: The OP chooses the newest open circuit (or creates a new one) It chooses an appropriate OR on the selected circuit as the exit point It opens a stream by sending a relay begin cell to the exit node using a new streamID The exit node sends back a relay connected cell once it connects to the destination host The OP notifies the application of the connection and begins accepting data on the application’s TCP stream The OP packages the data and sends it using relay data cells Closing streams The exit node sends a relay end cell towards the OP Each OR in the circuit responds with its own relay end cell

Opening and Closing Streams Alice opens a stream and begins fetching a web page Relay c1{{ End}} Relay c2{End} (TCP Close) Relay c2{End} Relay c1{{ End}} Alice closes the stream

Integrity Checking Traffic could be compromised if only encryption is used Adversary could guess encrypted content and alter it to achieve desired effect Per-hop integrity checking Check integrity of relay cells using hashes or an authenticating cipher at every hop Drawbacks of per-hop integrity checking The approach imposes message-expansion overhead ORs would not be able to produce suitable hashes for intermediate hops Provides no additional information to the attacker since end-to-end timing attacks are possible

Tor’s Integrity Checking Tor’s integrity checking approach Check integrity at the edges of each stream Initial SHA-1 digest set at the time of key negotiation as a derivative of negotiated key Digest added incrementally to all relay cells exchanged First 4 bytes of current digest added to each cell Digest is encrypted as a part of the relay header

Rate Limiting & Fairness Volunteers are more willing to run services that can limit their bandwidth usage Limit number of incoming bytes not to overwhelm volunteer ORs Preferential treatment of interactive streams Preferential treatment presents a possible end-to-end attack

Congestion Control Needed in addition to bandwidth rate limiting to prevent circuit congestion Additional to TCP congestion control Two-fold congestion control: circuit-level throttling & stream-level throttling Throttling uses two windows: Packaging: tracks number of cells packaged by the OR and directed towards the OP Delivery: tracks number of cells OR is willing to deliver outside the network Each window is initialized to maximum allowable value (e.g. 1000) When a certain block of cells (e.g. 100) is packaged or delivered, the window size is decremented The OR sends a relay sendme cell towards the client’s OP The receiving OR increments its window size by the block size (100 in this case)

Congestion Control w = 1000 w = 200 100 cells send me w = 1000 w = 200 w window size

Rendezvous Points & Hidden Services Rendezvous points are a building block for location-hidden services which aim to achieve responder anonymity They allow clients to connect to service providers without revealing the latters’ IP addresses Goals Access control Robustness Smear-resistance Application-transparency

Rendezvous Points & Hidden Services Providing location-hidden services is achieved by: The server advertises a set of ORs as introduction points (IP) The client chooses an OR as a rendezvous point (RP) and builds a circuit to it The client contacts one of service provider’s introduction points and informs it of its RP If the service provider wants to respond to the client, it builds a circuit to the client’s RP The RP connects the client’s circuit to the service provider’s circuit The client send an relay begin cell to the service provider over the established circuit The communication resumes as before

Distributed Hashing Concept (e.g. Chord) Keys assigned to nodes with consistent hashing SHA-1 is used as the base hash function Consistent hashing has desirable load balancing properties Question: What is used as the indexing criteria for hidden services?

Requesting Service 1 Request Bob’s information 2 Bob’s information Lookup Service 1 Bob | IP1 | IP2 | IP3 2 6 IP1 RP 3 Bob’s OP Alice’s OP IP2 4 5 IP3 1 Request Bob’s information 2 Bob’s information 3 Build a circuit to RP 4 Contact Bob’s introduction point to request service 5 Relay Alice’s service request to Bob 6 Bob build a circuit to Alice’s RP

Exit Policies & Abuse Anonymity permits abusers to hide the origins of their activity Attackers can implicate exit nodes for their abuse When a system’s public image suffers, it can reduce the number and diversity of the system’s users  in this case, the anonymity group Tor allows each OR to specify an exit policy that describes to which external addresses and ports it will connect Open exit nodes will connect to anywhere Middleman nodes only relay traffic to other Tor nodes Private exit nodes only connect to a local host or network Restricted exit nodes prevent access to abuse-prone addresses and services

Exit Policies & Abuse Additional mechanisms: Port restriction Use proxies to clean outgoing traffic Rewrite outgoing traffic to indicate that it passes through an anonymizing network Question: Can static exit policies introduce potential for exploitation?

Directory Servers Directories in Tor are a small group of redundant, well-known onion routers to track changes in network topology and node state Each directory acts as an HTTP server, clients fetch network info ORs post signed statements to the directories Directories must be synchronized Tor assumes that a threshold of participants agree on the set of directory servers, with human administrators resolving problems when consensus cannot be reached Question: Why use directories instead of flooding or gossiping updates?

Passive Attacks Observing user traffic patterns Observing user content Option distinguishability End-to-end timing correlation End-to-end size correlation Website fingerprinting

Active Attacks Compromise keys Iterated compromise Run a recipient Run an OR DoS non-observed nodes Run a hostile OR Replace contents of unauthenticated protocols Replay attacks Smear attacks Distribute hostile code

Directory Attacks Destroy directory servers Subvert a directory server Subvert a majority of directory servers Encourage directory server dissent Trick the directory servers into listing a hostile OR Convince the directories that a malfunctioning OR is working

Attacks Against Rendezvous Points Make many introduction requests Attack an introduction point Compromise an introduction point Compromise a rendezvous point

Tor in the Wild As of Mid-May 2004 32 nodes (more joining each week) Each nodes has at least 768Kb/768Kb connection Several companies have taken use of Tor Processed 800,000 relay cells per week All of CPU time in AES Current latency (network latency, end to end congestion control)

Tor in the Wild As of Jan. 2006 Tor developers are looking for more sponsors As of Feb. 2006 Tor has grown to hundreds of thousands of users Pushing for more users to run servers to expand the Tor network Looking for help to improve the system and fix some critical bugs

Future Directions Scalability Bandwidth classes Incentives Cover traffic Caching at exit nodes Better directory distribution Wider-scale deployment

Conclusions When designing anonymity preserving systems, the main challenge is striking a balance between scalability, decentralization, and privacy Tor adds several enhancements to the original Onion Routing system, but there are still many open issues, vulnerabilities, and areas of future work More information is needed about the selection of volunteer ORs and circuit establishment