1 / 25

Tor – The Onion Router

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

domani
Télécharger la présentation

Tor – The 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. Tor – The Onion Router By: David Rollé

  2. 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?

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

  4. Goals and Non-Goals of Tor Goals • 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?

  5. 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?

  6. Tor Design

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

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

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

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

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

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

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

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

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

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

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

  18. Attack Methodologies and Defenses

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

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

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

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

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

  24. Other Attacks?

  25. 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?

More Related