Transcript Tor: The Second-Generation Onion Router

Tor: The Second-Generation
Onion Router
ROGER DINGLEDINE, NICK
MATHEWSON, PAUL SYVERSON
THE FREE HAVEN PROJECT
&NAVAL RESEARCH LAB
PRESENTED BY: COREY WHITE
Table of Contents
 Background Information
 Tor Enhancements over Original
 Related Work
 Design Goals and Assumptions
 The Tor Design
 Rendezvous Point and hidden Services
 Design Decisions
 Attack and Defenses
 Early experience: Tor in the Wild
 Open Questions in Low-Latency Anonymity
 Future Direction
 Conclusion
Background Information
 What is an Onion Routing (Original)?



Onion routing is an anonymous communication technique over a
computer network. Messages are constantly encrypted and then sent
through several network nodes called onion routers which creates a
circuit of nodes.
Each onion router removes a layer of encryption with its symmetric
key to reveal routing instructions, and sends the message to the next
router where this is process is repeated.
Thus the analogy “onion router”. This prevents these intermediary
nodes from knowing the origin, destination, and contents of the
message.
Background Information continued..
 What is Tor Onion Routing?: Second Generation Onion Routing




Tor is a distributed overlay network which anonymizes TCPbased applications (e.g. web browsing, secure shell, instant
messaging applications.)
Clients choose the circuit paths
Message are put in cells and unwrapped at each node or onion
router with a symmetric key.
The ORs only know the successor or predecessor but not any
other Onion Router.
Background Information
http://en.wikipedia.org/wiki/File:Onion_diagram.svg
Tor Enhancements over Previous Onion Routing
applications
 Tor uses telescoping path-built design
 Previous designs allowed hostiles to record traffic and
compromise successive nodes.
 Tor uses SOCKS proxy interface
 Previous designs required a separate application proxy for
each application protocol.
 Tor is able to share one circuit for many TCP streams
 Previous designs required a separate circuit for each
application level request. Which is a threat to anonymity.
 Leaky pipe circuit topology
Tor Enhancements over Previous Onion Routing
applications continued..
 Directory servers
 Previous designs resorted to flooding info on the network.
 Variable exit policies
 End-to-end integrity checks
 Previous designs had no integrity checks.
 Rendezvous points/hidden services
 Previous designs included replay onions.
 Congestion control: uses end-to-end acks
 Previous designs didn’t address traffic bottlenecks.
Related Work
 Chaum’s Mix-Net design
 Correspondence hiding between sender & receiver by
wrapping messages in layers and relaying through “mix”
routers.
 Babel ‘s Mix master and Mixminion
 Try to maximize anonymity at the cost of high latency.
 Anonymizer
 Single-hop proxy
 PipeNet
 Low-latency design giving user anonymity by shutting down
the network by not sending.
Related Work
 P2P Tarzan and MorphMix designs
 Rely and generate traffic for other participating users and hide
who originated or relayed a request.
 Hordes/Crowds
 Hides the initiator of traffic thorough multicast responses
 Freedom
 Supports session keys and address of the server in a circuit.
 Rennhard’s Anonymity Network
 Builds circuits in stages which helps to obtain perfect forward
secrecy by extending them one hop at a time.
Design Goals and Assumptions
 Main Goals: Disrupt attackers from linking
communication partners, or from linking multiple
communications to or from a single user.
 Sub Goals:


Deployability: must be inexpensive to implement (e.g.
requiring kernel patches), can’t require non-anonymous
parties like websites to run the software.
Usability: a security requirement to hide users among users
which should not require modification of applications, no
prohibitive delays, and few configuration decisions, and easy
implementation on all common OS platforms.
Design Goals and Assumptions continued..
 Sub Goals:
 Flexibility: the protocol should be flexible and well specified
for future research work.
 Simple design: the protocols design and security must be user
friendly.
 Non Goals or Weaknesses
 No peer to peer environments
 Unsecure against end-to-end attacks
 No protocol normalization-Tor must be layered with filtering
proxy when using variable protocols like HTTP.
 No steganographic-Tor doesn’t conceal who is connected on
the network
Design Goals and Assumptions continued..
 Thread Model
 Passive adversaries are the most common threats
 They can also launch active attacks by compromising keys and
or routers, deny service to trustworthy routers to force users
toward compromised routers, or deny service to users to see if
other traffic stops.
 Adversaries also can subvert directory servers and decrease
node reliability by attacking nodes or by performing antisocial
activity from reliable nodes in order to take them down.
 Tor aims to prevent traffic analysis attacks, where the
adversary uses traffic patterns to learn which points of the
network to attack.
Tor Design
 Tor is an overlay network
 Each router has a user-level process w/o special privileges.



Each onion router maintains a TLS connection to every other
onion router.
Each user runs local software called onion proxy (OP) to fetch
directories, establish circuits across the network, and handle
connections from users.
Each router maintains a long-term & short term onion identity
key. These are used to sign TLS certificates which sign the
OR’s router descriptor(summary of keys, address,
bandwidth ,etc.)
Tor Design continued..
 Cells
 Traffic passes along the connections in fixed-sized cells which
are 512 bytes with a header and a payload.
 Cells consists of a header(circuit identifier or circID) to
determine which circuit the cell refers to. Also a command to
describe what to do about the cell’s payload.
 Cells are either control cells: always interpreted by the nodes
that receive them or…
 relay cells: which carry end-to-end stream data. Also relay cells
have an additional header on front of the payload containing a
streamID, integrity checksum, length of payload and relay
command.
Tor Design continued..
 Relay Commands
 Relay data: data flowing down stream
 Relay begin: to open a stream
 Relay end: to close a stream cleanly
 Relay teardown: to close a broken stream
 Relay connected: to notify successful relay begin
 Relay extend/extended: to extend the circuit by a hop
 Relay send me: congestion control
 Relay drop: implements long-range dummies
Tor Design continued..
Alice builds a two-hop circuit and begins fetching a web page.
https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.html
Tor Design continued..
 Relay Cells
 Once a connection is established a user can send relay cells
(relay truncated, destroy, create cells)

OR receive relay cells, look up the corresponding circuit and
decrypts the relay header and payload with the session key for
the circuit. Also checks for a valid digest for outgoing cells.

If not valid, the OR finds the circID for the next step in the
circuit, replaces the appropriate circID, and sends the
decrypted relay cell to the next OR.
Tor Design continued..
 Opening and Closing Streams
 A user like Alice can obtain a TCP connection via SOCKS
 The OP chooses a new open circuit and suitable OR to be an
exit node
 The OP then sends a relay begin cell to host, the host responds
with relay connected cell.
 The SOCKS relays to notify its success.
 The OP now accepts data from the TCP stream, which is
packaged into relay data cells and passes these to the intended
OR.
 SOCKS’s weakness is revealing of user destinations if the
intended application does DNS resolution first.
Tor Design continued..
 Integrity Checking on Streams
 Integrity checks are only done at the edges of each
stream(leaky-pipe circuit topology allows a streams edge to be
any hop in the circuit)
 The OP and the hop initialize a SHA-1 digest with a derivative
of the key, then both add to the digest the contents of all relay
cells they create.
 Each side also keeps a SHA-1 digest of data received , to verify
correctness of the hashes.
 A cell has four bytes to lower overhead, which leaves an
adversary’ chances of guessing a valid hash to very low, also
the OP or OR tear down the circuit if they get a bad hash.
Tor Design continued..
 Rate limiting and fairness
 Tor uses a token bucket approach to enforce long-term average
rate of incoming bytes, while still allowing short-term bursts
above the allowed bandwidth to limit bandwidth usage.

Tor provides good latency for interactive streams and good
overall throughput to the bulk streams by acting as if the entire
cell has been read disregarding the cell’s fullness. The local
application may be waiting for a reply and this method
accomadates this position without waiting for more bytes.
Tor Design continued..
 Congestion Control (circuit-level throttling)


Each OR keeps track of two windows, the packaging window: tracks
how many relay data cells allowed to the OR for packaging back to
the OP. The delivery window: tracks how many relay data cells given
to TCP streams outside the network.
OR after receiving enough data cells, it sends a send me relay to the
OP with streamID zero. It then increments the packaging window by
100. If the window reaches 0 the OR stops reading from TCP
connections for all streams on the corresponding circuit, and stops
until another send me relay is received
 Congestion Control (Stream-level throttling)

Similar to circuit level throttling but checks for successful flushed
TCP stream, and only sends “send me” relays when flushed under a
set threshold by the user.
Rendezvous Points and Hidden Services
 Rendezvous points are building blocks for location-hidden
services(responder anonymity)
It allows an OP to offer a TCP service without revealing his IP
address. This protects against DoS attacks.
 Goal for location hidden servers
 Access-control: filters incoming requests to prevent flooding
 Robustness: Users maintains a long-term pseudonymous identity
even during failure
 Smear-resistance: frame prevention on rendezvous routers
 Application transparency: no modification of user special software.
Rendezvous Points continued..
 Rendezvous Points in Tor






User 1 generates a long-term public key pair to identify his service.
User 1 chooses some introduction points, and advertises them on the lookup
service, signing the advertisement with his public key.
User 1 builds a circuit to each of his introduction points, and tells them to
wait for requests.
User 2 learns about User 1 ’s service out of band (perhaps via lookup service
If user 2 wants to access User 1 ’s service anonymously, she must connect
via Tor to the lookup serivce.
User 2 chooses an OR as the rendezvous point for her connection to user 1’s
service. She builds a circuit to the RP, and gives it a randomly chosen
“rendezvous cookie” to recognize user 1.
User 2 opens an anonymous stream to one of user 1’s introduction points,
and gives it a message (encrypted with User 1’s public key) telling the RP
and rendezvous cookie, and the start of a DH handshake. The introduction
point then sends the message to user 1.
Rendezvous Points continued..




If User 1 wants to talk to user 2 he builds a circuit to user 2’s
RP and sends the rendezvous cookie, the second of half of the
DH handshake, and a hash of the session key they now share.
By the same argument, this enables user 2 of knowing she
shares the key only with user 1.
The RP connects user 2’s circuit to user 1’s. at this point the
RP can’t recognize user 2, user 1, or the data they transmit.
User 2 sends a relay begin cell along the circuit. It arrives at
user 1’s OP, which connects to user 1’s web server.
An anonymous stream has been established, and user 2 and
user 1 can now communicate as normal.
Other Design Decisions
 DoS and Tor
 Tor is vulnerable to DoS attacks because users can consume
more network resources than allowed or render the network
unusable for other users.
 Tor deals with these attacks with
 Puzzle solving: done at the beginning of a TLS handshake or
accepting create cells, this limits the attack multiplier.
 Limiting rates: this limits the rates of accepting of create cell
and TLS connections so the computational work of processing
them doesn’t disrupt the symmetric cryptography operations
that allow cells to flow.
Other Design Decisions continued..
 Exit Policies and Abuse: Tor deals with abuse
thorough its abuse policy including..




Exit Policy: tells which external addresses and ports will
connect to where.
Open exit nodes: connect anywhere
Middleman nodes: only relay traffic to other Tor nodes.
Private exit nodes: allows a client to connect more securely to a
host. This prevents eavesdropping.
Other Design Decisions continued..
 Directory Servers
 Tor uses small group of onion routers to track changes in
network topology and node state, including keys and exit
policies.
 These directory servers act as HTTP servers that fetch state
and router lists, and allows for other ORs to upload state
information.
 The directory servers combine this info with their own network
liveliness and generate the signed description or directory of
the entire network.
 All new nodes must be approved by the directory servers and
their keys to prevent attackers from taking over the network by
creating many servers.
Attacks and Defense
 Passive Attacks
 Observing traffic patterns: Observance of user traffic will not
reveal destinations or date, but reveals patterns of sent and
received data.
 Observing user content: Tor uses Privoxy and related filtering
service to anonymize application data streams.
 Optional distinguishability: allows for clients to choose
configuration options but is a threat to anonymity.
 End-to-end timing correlation: hides the connection between
the onion proxy and the first Tor node, this runs the OP on the
Tor node and or behind the firewall.
Attacks and Defense


End-to-end size correlation: simple packet counting is effective
attack which confirms endpoints of a stream.
Website fingerprinting: Is a database of patterns of file sizes
and access patterns for targeted websites. This is less effective
against Tor because it’s streams are multiplex within the same
circuit.
Attacks and Defense
 Active Attacks
 Compromise keys: Compromised session keys that leave
control cells and encrypted cells on every circuit on the
connection vulnerable.
 Iterated compromise: This is compromising of the ORs, this is
hindered because session keys are forward in secrecy, which
won’t allow nodes to decrypt recorded traffic once the circuit
is closed.
 Run a recipient: an adversary learns the timing patterns of
connecting users and introduces arbitrary patterns in its
response.
Attacks and Defense





Onion Proxy: compromising of onion proxies compromises all
future connections through it.
Tagging attacks: hostile nodes tag a cell by altering, but
integrity checks on cells prevent this attack
Replay attacks: Tor is not vulnerable to replay attacks because
of protocols of session keys during a handshake.
Smear attack: Exit policies deter the abusive socially
unacceptable acts on the network.
Distribute hostile code: tricks users into running subverted Tor
software that reduces their anonymity.
Attacks and Defense
 Directory Attacks
 Destroying directory servers: few destroyed directories won’t
effect the network, but half destroyed is harmful because it
doesn’t have enough to display a view of the network and give
a consensus directory.
 Subvert a directory server: compromising a directory server an
attacker can influence the view of the final directory.
 Subvert a majority of directory servers: allows for
compromising of ORs in the final directory
 Trick the directory servers into listing a hostile OR: This is
deterred by Tor’s directory server operators filtering out
hostile ORs.
Early Experiences: Tor in the Wild
 Tor network
 Tor as of May 2004, has 32 nodes( 24 in the US , 8 in Europe)
 Each node has 768/768 connection and many have 10 Mb.
 Each node processed 800,000 relay cells per week
 Tor has been used for web browsing, FTP, IRC, Kazaa, etc.
 Latency attributed to two factors: bouncing of traffic around
the world several times and end-to-end congestion which
protects users from DoS.
Open Questions in Low-Latency Anonymity
 How often should users rotate to fresh circuit?:
 Frequent rotation is expensive and inefficient and could lead to
attacks, while infrequent rotation make the user’s traffic
linkable.
 How to choose path lengths?:
 using two hops per user could disrupt anonymity because of
the timing pattern it could create.
 How to disrupt end-to-end confirmation?:
 affects both high and low latency systems. Tor uses long-range
wrapping of control commands in similar looking relay cells to
reduce to chance of this attack.
Future Directions
 Tor wants to improve on
 Scalability
 Bandwidth classes: advertisement of bandwidth levels
 Incentives: rewards including publicity and better anonymity
 Cashing at exit nodes: running a cache proxy
 Better directory distribution: distribute up-to-date network
snapshots
 Further specification review: more external review of Tor
 Multisystem interoperability: allow more testing design
comparisons
 Wider-scale deployment: more users for better design
evaluation
Conclusion
 Tor is great with providing anonymity ,deterring
replay attacks and ensuring integrity checks. It is
very versatile allowing web- browsing FTP, IRC,
AIM, Kazaa, SSH, and recipient-anonymous email
via rendezvous points.
 Unfortunately its vulnerabilities to several passive
and active attacks within its network at critical areas
leave it in need of vast improvements and research
in the future.