v the second generation
Download
Report
Transcript v the second generation
Tor – The
Onion Router
By: David Rollé
What is Tor?
Second generation Onion Routing
Aims to improve on first generation issues
Perfect Forward Secrecy
Ease of deployability and use
Remove superfluous information
Multiplex streams
Leaky-Pipe Circuit Topology
Congestion Control
Directory Servers
Variable Exit Policies
Integrity Checking End-to-End
Rendezvous Point
Why?
Background of Problem
Tracking information throughout the world
China
Is anonymity on the internet really necessary?
Prevalence of cyber crimes?
Global adversaries versus limited adversaries
Facebook versus your evil cyber-neighbor Bob
How critical is Tor in today’s society?
SOPA and PIPA
E.g. – Leverage
Exit Abuse?
Paper is from 2004, dated by several years. Tor has
evolved substantially since this paper’s publishing,
adding many layers of security.
Goals and Non-Goals of Tor
Goals
Deployability
Usability
Flexibility
Simple design
Deferred Goals
Not Peer-to-Peer
Not Secure from End-toEnd attacks
Not protocol normalized
Why wasn’t this
emphasized?
No UDP. Good or bad?
Doesn’t conceal who is
connected to network.
Why not?
Low-Latency vs. High-Latency
Low Latency Advantages
Can run regular
webpages, with
Javascript and JSON
technology in near
realtime.
Low Latency
Disadvantages
Can’t obfuscate data
too much; data has
time limits for expiration
High-Latency Pros
Lots of time to obfuscate
data, with multiple layers of
encryption and reordering
of end traffic.
High-Latency Cons
Limits the usefulness of the
technology, as email servers
and other important request
servers cannot work with
materials
Which do you think is more efficient at safeguarding anonymity?
Tor Design
Onion Router
TLS Connection to every other Onion Router
Can only see previous router and router
ahead
Previously a problem in old architecture. How?
Verified by directory servers to create map
Can interpret CircID’s to send data to another
location
Efficiency problem? Better solutions?
Has identity key to verify its information
Onion Proxy
Local
software for the user
Fetches Directories
Establishes circuits across network
Handle connections from user applications
Multiplexes
TCP streams across circuits
Handles the routing from end to end
Cell Technology
Circuit
ID (assigned at start, interpreted at
router by key)
Control Cells
CircID and CMD
Relay
Cells
Includes Relay, StreamID, Digest, Length of
cell, as well as the CircID and CMD
Digest critical to Leaky-Pipe algorithm
Circuit Technology
Onion
Routing with a twist
Construct Circuits
Long time to construct a complete circuit
Short time to add/subtract from
Consider rotating circuits once a minute
Destroy
Circuits
Relatively quick, useful for rerouting the
circuit through different ORs in case of
circuit breakage
Circuit Creation
OP connects to OR with TLS secure
New CircID, uses a Control Cell to carry data.
OR responds with the second half of the DiffieHellman handshake
OP encrypts additional Control Cell and sends
them to OR, waits for response, etc.
End result: Multiple layers of encryption, easily
translated by OR. Also, Digest allows multiple
exit points along circuit
Build longer circuit than necessary.
Streams
OP
is asked for a connection via SOCKS
Each stream has random stream ID
Why is this important?
Problems
with SOCKS
Applications can pass the hostname to the
Tor Client, or pass the IP address first
If DNS reolution performed, Alice reveals
location of both ends.
Solutions?
Integrity Checking via Digest
The Digest is comprised of encoded bits
which verify when the cell is completely
decoded
Lynchpin for Leaky-Pipe algorithm
ORs verify stream is not in still in transit
Digest pre-negotiated at circuit creation using
SHA-1 digest with derivative of the key
Digest serves Leaky-Pipe topology and
Integrity checking
Throttle Control
Rate
Limiting
Bulk stream versus interactive stream
Fairness
Token Bucket Approach
Enforces
average rate of incoming bytes
Permits short term bursts above bandwidth
allotment
Cannot
always wait for a full cell, send
when possible
Congestion Control
Circuit
Level Throttling
Packaging Window
Delivery Window
Relay sendme cell
Stream
Level Throttling
Similar construction to circuit level throttling,
just one level up the Open Systems
Interconnection (OSI) model
Rendezvous Points
Requirements:
Introduction Points
Obtained from an RP, given to the introduction point to connect
server to client
Rendezvous Point
Hidden server creates circuits to each introduction point (advertised
ORs), and can hide some for only select clients
Rendezvous cookie
Access-Control, Robust, Smear-resistant, Application-Transparent
Server connects with second half of handshake from token, and RP
connects two circuits together
Client initiates contact directly, and regular Tor operations
commence
Why are these not available from outside of Tor?
Could it be possible to make them available outside of Tor?
Possibly have an OP handle the requests, and translate them into
RP?
Con: Makes OP liable to attack from adversaries.
Design Defenses
DoS defense
Exit Policies
Flow Control and Rate Limiting help, but other ideas
need to be implemented.
Open, Restricted (Some restrictions apply), Middleman
(no connection outside Tor), Private (Only connect to
local network)
Exit abuse hurts capabilities of Tor’s anonymization.
Directory Servers
Previously in-band updates: Entire network obtained all
of the states at varying times.
Directories currently act as policemen of new nodes;
new nodes require human intervention.
Directories synchronized and redundant.
Attack
Methodologies
and Defenses
Passive Attacks
Observe Traffic Patterns
Observe User Content
Tor does not hide timing (low-latency requirement)
End-to-end Size Correlation
Leads to tracing due to distinct pattern behavior
End-to-end Timing Correlation
Use of Privoxy
Option Distinguishability
Multiplexing minimizes damage
Leaky-Pipe Topology
Website Fingerprinting
New attack as of 2004, semi-defended by mitigation
Active Attacks
Compromise Keys
Mitigated by key rotation and redundant multiple layer encryption. Replacing a
node via identity key could theoretically avoid this defense.
Iterated Compromise
Run Recipient
Only real defense is robustness
Run hostile OR
Compromised OPs compromise all information sent through OP
DoS non-observed nodes
Adversary controls end server, which allows him to use Tor to attack the other
end. Privoxy would help minimize chance of revealing initiator
Run Onion Proxy
Short lifetimes for circuits
Requires nodes at both ends of a circuit to obtain information
Introduce Timing
Similar to timing discussed in passive version
Active Attacks continued
Tag Attacks
Replay Attacks
No real solution, verify that server is actually server
with authentication. Similar to Recipient attack
Smear Attacks
Session key changes if replay used
Replace End Server
Integrity check mitigates this
Good press and exit policies
Hostile Code Distribution
All Tor releases signed
Directory Subversion
Destroy Servers
Subvert Server
People problem, not Tor problem.
Trick Directories
Ensure Directories are independent and resistant to attacks
Encourage Dissent in Directory Operators
At worst, cast tie-breaker vote
Subvert Majority of Servers
Directories require majority rule, or human intervention if more
than half destroyed.
Server Operators should be able to filter out hostile nodes.
Convince Directories that OR is Functional
Directory servers should test by building circuit and streams to
OR.
Rendezvous Point Attacks
Many Introduction Point Requests
Attack Introduction Point
Server re-advertises on different IP, or advertise
secretly. Attacker must disable all IPs.
Compromise Introduction Point
IP can block requests with authorization tokens, or
require certain amounts of computation per
request.
Servers should occasionally verify their IPs, and
close circuits that flood them.
Compromise Rendezvous Point
Similar to active attacks against ORs
Other
Attacks?
Food For Thought
Global
adversaries: Paper never touches
on adversaries with large programming
armies behind them. Can Tor be useful
and efficient in environments such as
China?