Transcript The Tor Design

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)
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*
Server 1
Server 2
m1
m2
Decrypt &
Permute
Server 3
Decrypt &
Permute
m3
Decrypt &
Permute
m2
m2
m3
m1
m1
m3
m1
m2
m3
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 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 = 200
w = 1000
w = 1000
100 cells
send me
w = 200
w = 1000
100 cells
send me
w = 200
w = 900
w = 900
w = 1000
w = 1000
w = 1000
100 cells
w = 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
Bob | IP1 | IP2 | IP3
1
6
2
IP1
3
Alice’s
OP
1
2
3
4
5
RP
IP2
4
IP3
Request Bob’s information
5
Bob’s information
Build a circuit to RP
Contact Bob’s introduction point to request service
Relay Alice’s service request to Bob 6 Bob build a circuit to Alice’s RP
Bob’s
OP
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