Download Document

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Airborne Networking wikipedia , lookup

Distributed firewall wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Remote Desktop Services wikipedia , lookup

Lag wikipedia , lookup

Transcript
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?