1 / 19

Tor: The Second-Generation Onion Router

Tor: The Second-Generation Onion Router. Roger Dingledine, Nick Mathewson, Paul Syverson. Introduction. Second Generation of Onion Routing Focus on deployability Perfect forward secrecy Separation of “protocol cleaning” from anonymity No mixing, padding or traffic shaping

mac
Download Presentation

Tor: 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. Tor: The Second-Generation Onion Router Roger Dingledine, Nick Mathewson, Paul Syverson

  2. Introduction • Second Generation of Onion Routing • Focus on deployability • Perfect forward secrecy • Separation of “protocol cleaning” from anonymity • No mixing, padding or traffic shaping • TCP Streams can share on circuit • Leaky-pipe circuit topology

  3. Introduction • Congestion control • Directory servers • Exit policies • Integrity checking • Hidden services

  4. Design Goals • Deployability • Usability • Flexibilty • Simple Design

  5. Non-Goals • Not P2P • Not secure against end to end attacks • No protocol normalization • Not steganographic

  6. Threat Model • Does not protect against a global passive adversary • Adversary can: • Generate, modify, delay and delete traffic • Operate onion routers • Compromise many onion routers • Aim is to project gains traffic analysis attacks not traffic confirmation attacks • What do you all think of this distinction? Is it valid?

  7. Design • Overlay network • Onion routers route traffic • Onion Proxy fetches directories and creates circuits on the network • Uses TCP • All data is sent in fixed size cells Data CircID CMD StreamID Digest Len CMD Data CircID Relay

  8. Circuits • Describes the Onion Routers on the path • Can be used by many TCP streams • Built incrementally

  9. Building a circuit Create c2 E(gx2) Created c2, gy2, H(K2) Created c1, gy1, H(K1) Relay c1(Extended, gy2, H(K2) Create c1, E(gx1) Relay c1 (Extend, OR2, E(gx1))

  10. Fetching a web page Relay c2 (Begin <Bob>) Relay c2 (Connected) Relay c1 (Connected) TCP Handshake Relay c1 (Begin <Bob>) Last onion router should get the IP address of Bob’s website to protect Alice’s anonymity.

  11. Additional functionality • Integrity checking • Only done at the edges of a stream • SHA-1 digest of data sent and received • First 4 bytes of digest are sent with each message for verification • Rate limiting • Uses token bucket approach • Interactive streams get preferential treatment

  12. Congestion Control • There is some concern about OR-to-OR congestion • Circuit Level throttling • 2 windows keep track of relay data to be transmitted to other ORs and data transmitted out of the network • Windows are decremented after forwarding packets and increments on a relay sendme message • When a window reaches 0, no messages are forwarded

  13. Congestion Control • Stream Level Throttling • Streams have packaging windows associated with them • The window is decremented was messages are sent and incremement when relay sendme are received • relay sendme messages are sent after the TCP stream has flushed a certain number of bytes • This congestion control method is pretty primitive. Why not leverage existing work here?

  14. Hidden Service and Rendezvous Points • Tor accommodates receiver anonymity by allowing location hidden services • Design goals for location hidden services • Access Control • Robustness • Smear-resistance • Application transparency • Location hidden service leverage rendezvous points

  15. Creating and connecting to a Location hidden service

  16. Other design decisions • DoS • CPU consumption attacks are possible • Crashing routers also causes a DoS • Exit Policies and Abuse • As with other systems, abuse is a big deal • Routers can specify exit policies restricting how they are used • Directory Services • Advertises current network states and routers

  17. Attacks and Defenses • Passive Attacks • Observing user content • End-to-end timing correlation • Active Attacks • Compromising Keys • Run a hostile OR • Attacks on the Directory Service • Destroy directory service • Subvert 1 or more directory servers • Attacks against rendezvous points • Make many introduction requests • Compromise a rendezvous point

  18. Tor in the wild • There is a current deployment of Tor • Currently ~ 350 Tor routers • ~ 40MB read and write at any given time • Performance • 42% increase in time for large file • Varied for interactive sessions

  19. Discussion Questions • In Tor, if your entry node and exit node are compromised, you are sunk. If this is the case, what is the point of circuits with more then 2 hops? • One of the tensions for Tor (and other anonymity systems) is that they need a good user base to improve the system. However, the anonymity the offer isn’t great. How do you get people to use such a system?

More Related