Tor – The Onion Router
description
Transcript of Tor – The Onion Router
Tor – The Onion RouterBy: 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? E.g. – Leverage
Global adversaries versus limited adversaries Facebook versus your evil cyber-neighbor Bob
How critical is Tor in today’s society? SOPA and PIPA
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 TorGoals Deployability Usability Flexibility Simple design
Deferred Goals Not Peer-to-Peer Not Secure from End-to-
End attacks Why wasn’t this
emphasized? Not protocol normalized
No UDP. Good or bad? Doesn’t conceal who is
connected to network. Why not?
Low-Latency vs. High-LatencyLow 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 interpret CircID’s to send data to another location
Can only see previous router and router ahead Previously a problem in old architecture. How?
Verified by directory servers to create map 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 Diffie-
Hellman 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:
Access-Control, Robust, Smear-resistant, Application-Transparent Introduction Points
Hidden server creates circuits to each introduction point (advertised ORs), and can hide some for only select clients
Rendezvous cookie Obtained from an RP, given to the introduction point to connect
server to client Rendezvous Point
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
Flow Control and Rate Limiting help, but other ideas need to be implemented.
Exit Policies 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
Multiplexing minimizes damage Observe User Content
Use of Privoxy Option Distinguishability
Leads to tracing due to distinct pattern behavior End-to-end Timing Correlation
Tor does not hide timing (low-latency requirement) End-to-end Size Correlation
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 Short lifetimes for circuits
Run Recipient 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
Compromised OPs compromise all information sent through OP DoS non-observed nodes
Only real defense is robustness Run hostile OR
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
Integrity check mitigates this Replay Attacks
Session key changes if replay used Replace End Server
No real solution, verify that server is actually server with authentication. Similar to Recipient attack
Smear Attacks Good press and exit policies
Hostile Code Distribution All Tor releases signed
Directory Subversion Destroy Servers
Directories require majority rule, or human intervention if more than half destroyed.
Subvert Server At worst, cast tie-breaker vote
Subvert Majority of Servers Ensure Directories are independent and resistant to attacks
Encourage Dissent in Directory Operators People problem, not Tor problem.
Trick Directories 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
IP can block requests with authorization tokens, or require certain amounts of computation per request.
Attack Introduction Point Server re-advertises on different IP, or advertise
secretly. Attacker must disable all IPs. Compromise Introduction Point
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?