The Second-Generation The Second-Generation Onion RouterOnion 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)

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

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*

m1

m2

m3 m1

m3

m2

m2

m3

m1

m2

m1

m3

Decrypt & Permute

Decrypt & Permute

Decrypt & Permute

Server 1 Server 2 Server 3

Ciphertext = EPK1[EPK2[EPK3[m]]]

Relay Based Systems

High 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

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

Deployment• 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 2

OR 3

Server

OP

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

Relay c1{Truncate}Relay c2{Destroy}

Relay c1{Truncated}

Alice OR 1 OR 2

Alice builds a two-hop circuit

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 2 (exit)

OR 3 (exit)

Server

OP

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

Relay c1{{ End}}Relay c2{End}

(TCP Close)Relay c2{End}

Relay c1{{ End}}

Alice opens a stream and begins fetching a web page

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 = 1000w = 1000w = 200

100 cellssend me

100 cellssend me

100 cells

w = 1000w = 200 w = 900

w = 900 w = 1000w = 200

w = 1000w = 1000w = 100

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

Lookup Service

Alice’s OP

Bob’s OP

Bob | IP1 | IP2 | IP3

IP1

IP2

IP3

RP

1

2

3

4

5

6

1 Request Bob’s information2 Bob’s information3 Build a circuit to RP4 Contact Bob’s introduction point to request service5 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