Roger Dingledine, Nick Mathewson, Paul Syverson

1
Tor The Second-Generation Onion Router

• Roger Dingledine, Nick Mathewson, Paul Syverson
• The Free Haven Project Naval Research Lab
• Presented by Corey White

2
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

3
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.

4
Background Information continued..

• What is Tor Onion Routing? Second Generation
  Onion Routing
• Tor is a distributed overlay network which
  anonymizes TCP-based 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.

5
Background Information
http//en.wikipedia.org/wiki/FileOnion_diagram.sv
g
6
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

7
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 didnt address traffic
  bottlenecks.

8
Related Work

• Chaums 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.

9
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.
• Rennhards Anonymity Network
• Builds circuits in stages which helps to obtain
  perfect forward secrecy by extending them one hop
  at a time.

10
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), cant 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.

11
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 doesnt conceal who is
  connected on the network

12
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.

13
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 ORs router
  descriptor(summary of keys, address, bandwidth
  ,etc.)

14
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 cells 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.

15
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

16
Tor Design continued..
Alice builds a two-hop circuit and begins
fetching a web page.
https//www.torproject.org/svn/trunk/doc/design-pa
per/tor-design.html
17
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.

18
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.
• SOCKSs weakness is revealing of user
  destinations if the intended application does DNS
  resolution first.

19
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.

20
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 cells fullness. The local
  application may be waiting for a reply and this
  method accomadates this position without waiting
  for more bytes.

21
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.

22
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.

23
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 1s 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
  1s introduction points, and gives it a message
  (encrypted with User 1s 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.

24
Rendezvous Points continued..

• If User 1 wants to talk to user 2 he builds a
  circuit to user 2s 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 2s circuit to user 1s. at
  this point the RP cant recognize user 2, user 1,
  or the data they transmit.
• User 2 sends a relay begin cell along the
  circuit. It arrives at user 1s OP, which
  connects to user 1s web server.
• An anonymous stream has been established, and
  user 2 and user 1 can now communicate as normal.

25
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 doesnt
  disrupt the symmetric cryptography operations
  that allow cells to flow.

26
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.

27
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.

28
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.

29
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 its streams are multiplex within the
  same circuit.

30
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 wont 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.

31
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.

32
Attacks and Defense

• Directory Attacks
• Destroying directory servers few destroyed
  directories wont effect the network, but half
  destroyed is harmful because it doesnt 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 Tors directory
  server operators filtering out hostile ORs.

33
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.

34
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 users 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.

35
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

36
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.