1 / 48

The Second-Generation Onion Router

This presentation discusses the second-generation Onion Router (Tor) and its goals, improvements, implementation, threat model, deployment, and future directions. It explores the concept of anonymity, modern anonymity systems, and the original Onion Routing. The presentation also covers the importance of anonymity, various levels of anonymity, and the difference between anonymity and pseudonymity.

mavisd
Download Presentation

The Second-Generation Onion Router

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Second-Generation Onion Router R. Dingledine, N. Mathewson, P. Syverson Presented By: Enrico Chandler Maryam Jafari-Lafti

  2. Presentation Outline • What is anonymity? • Modern Anonymity Systems • The original Onion Routing • Tor’s goals and improvements • Tor implementation • Threat Model • Tor in the wild • Future directions • Conclusions

  3. What is Anonymity? • Anonymity can be defined as maintaining (real-world) identifying information about a transaction and/or the communicating parties hidden • Why do we need anonymity? • Protecting “sensitive” activities, censorship resistant publishing, protecting against profiling, whistleblowing, etc. • Common types of anonymity: sender anonymity, receiver anonymity, unlinkability of the sender and receiver, unlinkability of transactions • Various levels of anonymity (application and/or network layer)

  4. Anonymity or Pseudonymity? • Anonymity vs. Pseudonymity • Full anonymity conflicts with accountability • Pseudonymity allows for authentication and establishment of trust • Actions could be linked back to a pseudonym (virtual identity) but most often not to the real-world identity

  5. Modern Anonymity Systems • Date back to Chaum’s Mix-Net design • Suggested hiding correspondence between sender and receiver by wrapping messages in layers of public key encryption • These messages would traverse a series of mixes en route to the receiver • Mixes decrypt, delay, and re-order messages before passing them onward

  6. m3 m2 Decrypt & Permute Decrypt & Permute Decrypt & Permute m1 m2 m3 m2 m3 m1 m1 m1 m2 m3 Basic Mix-Net Concept* Server 2 Server 1 Server 3 Ciphertext = EPK1[EPK2[EPK3[m]]]

  7. Relay Based Systems • High Latency • Babel, Mixmaster, Mixminion • Maximizes anonymity and the cost of large latencies • Networks resist strong global adversaries • Introduces too much lag for some TCP applications • Low Latency • Tor, Anonymizer, Pipenet • Attempt to anonymize interactive traffic which contain more packets that are time dependent • Handles a variety of bidirectional protocols • Time dependency of communications is a design concern

  8. The Original Onion Routing • Distributed overlay network to anonymize TCP-based applications • Client-side Onion Proxy (OP) chooses circuit of onion routers • An Onion Router (OR) is a server which receives messages from end nodes, batches and reorders them, and forwards them towards the destination • Messages are broken into fixed size cells and packaged into a data object called the “onion” via successive layers of encryption • As the onion traverses the circuit, the encryption layers are “peeled” off and the message is passed down to the next OR in the circuit

  9. The Original Onion Routing*

  10. Onion Routing Deployment • Deployed briefly • Fragile proof of concept on a single machine • Processed connections from over 60,000 IPs • Many critical design and deployment issues never resolved • Tor incorporates improvements over old onion routing

  11. Tor Design Goals & Non-Goals • Goals • Deployability • Usability • Flexibility • Simple Design • Non-Goals • Not peer-to-peer • Not secure against end-to-end attacks • No protocol normalization • Not designed to prevent traffic confirmation attacks • Design is aimed to prevent traffic analysis attacks

  12. Deployment & Usability • Deployment • Must be deployed and used in the real world • Not expensive to run • Not place a heavy burden on operators • Must not be difficult or expensive to implement • Can’t require non-anonymous parties to run software • Usability • Hard to use system equal fewer users which provides less anonymity • Should not require to modify familiar applications • Easily implementable on all platforms

  13. Flexibility and Simple Design • Must be flexible to serve as a test bed for future research • Design and security parameter must be well understood • Aim to deploy a simple and stable system that integrates the best accepted approaches to protecting anonymity

  14. Tor Improvements • Perfect forward secrecy • Separation of “protocol cleaning” from anonymity • Many TCP streams can share one circuit • Leaky-pipe circuit topology • Congestion control • Directory servers • Variable exit policies • End-to-end integrity checking • Rendezvous points and hidden services

  15. Improvements • Perfect forward secrecy • Original routing allowed recording of traffic • Tor uses incremental or telescoping path-building design • Onion replay detection is no longer necessary • Protocol cleaning from anonymity • Original routing required separate application proxy • Tor uses standard SOCKS proxy

  16. Improvements • Many TCP streams • Original routing built separate circuits • Multiple key operations • Threats to anonymity • Tor multiplexes multiple TCP streams • Leaky-pipe circuit topology • Tor initiators can direct traffic to nodes partway down circuit • This can possibly frustrate traffic shape and volume based on observing the end of circuit

  17. Improvements • Congestion control • Earlier anonymity designs do not address • Tor decentralizes congestion control with end-to-end ACKs • This maintain anonymity while allowing edge nodes to detect congestion or flooding • Directory servers • Original routing planned to flood state information through the network • Tor uses trusted nodes that act as directory servers to provide network state

  18. Improvements • Variable exit policies • Tor provides a mechanism for nodes to advertise host and ports to which it will connect • End-to-end integrity checking • Original routing did no integrity checking • Tor verifies data integrity before it leaves the network

  19. Improvements • Rendezvous points and hidden services • Original routing provided long lived reply onions • Did not provide forward security • Became useless if any node went down or rotated its key • Tor clients negotiate rendezvous points to connect to hidden servers • No reply onions are required

  20. Tor’s Design OR 1 OR 3 OR 2 OP Server Circuit

  21. Onion Routers & Proxies • Onion routers connect to destinations and relay user data • Onion router keys: • Identity key: long-term, signs TLS certificates, OR router descriptors, and directories if applicable • Onion key: Used with circuit establishment requests • TLS key: short-term, link level between ORs • Client-side OP is responsible for: • Fetching OR directories • Establishing circuits • Handling connections from applications

  22. Circuits & Streams • Circuits & Streams • A circuit is a set of intermediaries (ORs) for traffic indirection • One circuit for multiple TCP streams • Periodic background circuit set-up and expiration • Circuits built in increments (one hop at a time) • Question: What are the pros and cons of several cryptographic layers?

  23. Cells • Control cells: • Always interpreted, contains circID • Possible commands are: padding, create, destroy • Relay cells: • Include additional header, used to control various aspects of stream set-up and data transmission • Possible commands are: relay data, relay begin, relay end, relay teardown, relay connected, relay extend & extended, relay truncate & truncated, relay sendme, and relay drop

  24. Opening & Closing Circuits • Circuits are built preemptively and periodically to avoid delays and limit linkability • Circuits are build incrementally, negotiating a symmetric key with each OR in the circuit one hop at a time • Circuits can be closed incrementally by sending a relay truncate cell to a single OR and having it pass forward a relay destroy cell • Truncated circuits can be re-extended • Question: How can the circuit building/closing processes be exploited by malicious ORs? • Question: How long should circuits be? Fixed length or dynamic length?

  25. Opening & Closing a Circuit Alice builds a two-hop circuit Alice OR 1 OR 2 Relay c1{Truncate} Relay c2{Destroy} Relay c1{Truncated} Alice truncates its circuit to include only OR 1

  26. Leaky Pipe Circuits • The leaky pipe circuit topology allows client streams to exit at different ORs on a single circuit • The client may select different exit points based on their exit policies or to reduce linkability OR 1 OR 3 (exit) OR 2 (exit) OP Server Server

  27. Opening and Closing Streams • Given that the OP has a set of open circuits and it receives an application request for a TCP connection: • The OP chooses the newest open circuit (or creates a new one) • It chooses an appropriate OR on the selected circuit as the exit point • It opens a stream by sending a relay begin cell to the exit node using a new streamID • The exit node sends back a relay connected cell once it connects to the destination host • The OP notifies the application of the connection and begins accepting data on the application’s TCP stream • The OP packages the data and sends it using relay data cells • Closing streams • The exit node sends a relay end cell towards the OP • Each OR in the circuit responds with its own relay end cell

  28. Opening and Closing Streams Alice opens a stream and begins fetching a web page Relay c1{{ End}} Relay c2{End} (TCP Close) Relay c2{End} Relay c1{{ End}} Alice closes the stream

  29. Integrity Checking • Traffic could be compromised if only encryption is used • Adversary could guess encrypted content and alter it to achieve desired effect • Per-hop integrity checking • Check integrity of relay cells using hashes or an authenticating cipher at every hop • Drawbacks of per-hop integrity checking • The approach imposes message-expansion overhead • ORs would not be able to produce suitable hashes for intermediate hops • Provides no additional information to the attacker since end-to-end timing attacks are possible

  30. Tor’s Integrity Checking • Tor’s integrity checking approach • Check integrity at the edges of each stream • Initial SHA-1 digest set at the time of key negotiation as a derivative of negotiated key • Digest added incrementally to all relay cells exchanged • First 4 bytes of current digest added to each cell • Digest is encrypted as a part of the relay header

  31. Rate Limiting & Fairness • Volunteers are more willing to run services that can limit their bandwidth usage • Limit number of incoming bytes not to overwhelm volunteer ORs • Preferential treatment of interactive streams • Preferential treatment presents a possible end-to-end attack

  32. Congestion Control • Needed in addition to bandwidth rate limiting to prevent circuit congestion • Additional to TCP congestion control • Two-fold congestion control: circuit-level throttling & stream-level throttling • Throttling uses two windows: • Packaging: tracks number of cells packaged by the OR and directed towards the OP • Delivery: tracks number of cells OR is willing to deliver outside the network • Each window is initialized to maximum allowable value (e.g. 1000) • When a certain block of cells (e.g. 100) is packaged or delivered, the window size is decremented • The OR sends a relay sendme cell towards the client’s OP • The receiving OR increments its window size by the block size (100 in this case)

  33. w = 200 w = 1000 w = 1000 100 cells send me w = 200 w = 1000 w = 900 100 cells send me w = 200 w = 900 w = 1000 100 cells w = 100 w = 1000 w = 1000 Congestion Control w window size

  34. Rendezvous Points & Hidden Services • Rendezvous points are a building block for location-hidden services which aim to achieve responder anonymity • They allow clients to connect to service providers without revealing the latters’ IP addresses • Goals • Access control • Robustness • Smear-resistance • Application-transparency

  35. Rendezvous Points & Hidden Services • Providing location-hidden services is achieved by: • The server advertises a set of ORs as introduction points (IP) • The client chooses an OR as a rendezvous point (RP) and builds a circuit to it • The client contacts one of service provider’s introduction points and informs it of its RP • If the service provider wants to respond to the client, it builds a circuit to the client’s RP • The RP connects the client’s circuit to the service provider’s circuit • The client send an relay begin cell to the service provider over the established circuit • The communication resumes as before

  36. Distributed Hashing Concept (e.g. Chord) • Keys assigned to nodes with consistent hashing • SHA-1 is used as the base hash function • Consistent hashing has desirable load balancing properties • Question: What is used as the indexing criteria for hidden services?

  37. 1 6 2 3 4 5 Requesting Service Lookup Service Bob | IP1 | IP2 | IP3 IP1 RP Bob’s OP Alice’s OP IP2 IP3 1 Request Bob’s information 2 Bob’s information 3 Build a circuit to RP 4 Contact Bob’s introduction point to request service 5 Relay Alice’s service request to Bob 6 Bob build a circuit to Alice’s RP

  38. Exit Policies & Abuse • Anonymity permits abusers to hide the origins of their activity • Attackers can implicate exit nodes for their abuse • When a system’s public image suffers, it can reduce the number and diversity of the system’s users  in this case, the anonymity group • Tor allows each OR to specify an exit policythat describes to which external addresses and ports it will connect • Open exitnodes will connect to anywhere • Middlemannodes only relay traffic to other Tor nodes • Private exitnodes only connect to a local host or network • Restricted exitnodes prevent access to abuse-prone addresses and services

  39. Exit Policies & Abuse • Additional mechanisms: • Port restriction • Use proxies to clean outgoing traffic • Rewrite outgoing traffic to indicate that it passes through an anonymizing network • Question: Can static exit policies introduce potential for exploitation?

  40. Directory Servers • Directories in Tor are a small group of redundant, well-known onion routers to track changes in network topology and node state • Each directory acts as an HTTP server, clients fetch network info • ORs post signed statements to the directories • Directories must be synchronized • Tor assumes that a threshold of participants agree on the set of directory servers, with human administrators resolving problems when consensus cannot be reached • Question: Why use directories instead of flooding or gossiping updates?

  41. Passive Attacks • Observing user traffic patterns • Observing user content • Option distinguishability • End-to-end timing correlation • End-to-end size correlation • Website fingerprinting

  42. Active Attacks • Compromise keys • Iterated compromise • Run a recipient • Run an OR • DoS non-observed nodes • Run a hostile OR • Replace contents of unauthenticated protocols • Replay attacks • Smear attacks • Distribute hostile code

  43. Directory Attacks • Destroy directory servers • Subvert a directory server • Subvert a majority of directory servers • Encourage directory server dissent • Trick the directory servers into listing a hostile OR • Convince the directories that a malfunctioning OR is working

  44. Attacks Against Rendezvous Points • Make many introduction requests • Attack an introduction point • Compromise an introduction point • Compromise a rendezvous point

  45. Tor in the Wild • As of Mid-May 2004 • 32 nodes (more joining each week) • Each nodes has at least 768Kb/768Kb connection • Several companies have taken use of Tor • Processed 800,000 relay cells per week • All of CPU time in AES • Current latency (network latency, end to end congestion control)

  46. Tor in the Wild • As of Jan. 2006 Tor developers are looking for more sponsors • As of Feb. 2006 Tor has grown to hundreds of thousands of users • Pushing for more users to run servers to expand the Tor network • Looking for help to improve the system and fix some critical bugs

  47. Future Directions • Scalability • Bandwidth classes • Incentives • Cover traffic • Caching at exit nodes • Better directory distribution • Wider-scale deployment

  48. Conclusions • When designing anonymity preserving systems, the main challenge is striking a balance between scalability, decentralization, and privacy • Tor adds several enhancements to the original Onion Routing system, but there are still many open issues, vulnerabilities, and areas of future work • More information is needed about the selection of volunteer ORs and circuit establishment

More Related