2 ND GENERATION ONION ROUTER

Transcription

1 2 ND GENERATION ONION ROUTER Roger Dingledine, Nick Mathewson and Paul Syverson Presenter: Alejandro Villanueva

2 Agenda Threat model Cells and circuits Other features Related work How does it work? Rendezvous points & Hidden services Open Questions & Future directions (17) Design goals What is Tor? Advantages Attacks and Defenses 2

3 Threat model: Who are we defending from? A non-global attacker that can observe a fraction of the network s traffic. Can generate, modify, delete or delay traffic. Can operate (Onion) Routers on its own. Can compromise some fraction of the onion routers. Passive attacks To correlate traffic entering and leaving the network (timing, volume, user-selected options). Active attacks Compromise routers, keys; replay traffic, selectively deny service to push users to compromised routers or to see if traffic elsewhere stops, introduce patterns to be later detected. Typical goals Is Alice talking to Bob? Traffic analysis attacks: where the adversary uses traffic patterns to learn which points in the network he should attack. To build a profile of Alice s behavior. To attack directory servers To decrease network reliability. 3

4 In the beginning Chaum said: Let s mix! Let s hide correspondence between sender and recipient by wrapping messages in layers of public-key cryptography, and relay them through a path composed of mixes. Large and variable latencies: Forget about web browsing, chat or SSH High-latency networks Mix-Net Low-latency networks Many packets that have to be delivered quickly, easier to eavesdrop Babel Single-hop proxies Multi-hop proxies Mixmaster Anonymizer Java Anon Proxy PipeNet ISDN Mixes P2P designs Peers generate and relay traffic Mixminion Cascades: Fixed routes Tarzan MorphMix Crowds And Freedom, Cebolla, etc. Hordes Herbivore P^5 4

5 Design goals Low-latency Deployability Used in the real world. Not expensive to run. Light liability burden to operators. Neither difficult nor expensive to implement. Usability A hard-to-use system has fewer users, fewer users provide less anonymity: it s a security requirement. The least configuration decisions posible. Easily implementable on all common platforms. Flexibility Well-specified. A testbed for future research. Simple design Design and security parameters must be well understood. Avoid implementation and complexity costs. Prevent attackers from linking communication partners, or from linking multiple communications to or from a single user. Not looking for peer to peer, secure against end-to-end attacks, protocol normalization, concealing who s connected (steganographic). 5

6 Tor: Anonymity for the masses Onion Router: With long-term and short-term identity keys Onion Proxy: For users Circuit = Entry + Middle + Exit Router Directory Servers: Routers info Cells: Fixed-size communication unit An overlay network: A set of normal user-level processes running without special privileges on every router. Users run a local software called Onion Proxy. Onion Routers communicate via TSL connections with epheremeral keys. Anonymization of TCP streams through multiplexing circuits. Web-browsing, secure shell, mail, and instant messaging 6

7 How does it work? Onion Proxy connects to directory servers to choose an entry node. OP Alice sends an encrypted create cell to OR Bob with an initial handshake. OR Bob answers with a created cell and a hashed key in it. Alice sends relay extend cell to Bob with Carol s address and an encrypted handshake for her. Bob copies the content into a create cell for Carol. Carol answers with a created cell that Bob wraps into a relay extended cell to send it back to Alice. Alice and Carol share a common key now. 7

8 Cells and circuits Control cells: Always interpreted by the receiving node. Padding, create, created, destroy. Relay cells: Carry end-to-end stream data CircID change in every OP/OR OR/OR connection. StreamID because of stream multiplexing. Digest: Checksum for end-to-end integrity Length of relay payload Relay command Relay data, relay begin, relay end, relay teardown, relay connected, relay extend, relay extended, relay truncate, relay truncated, relay sendme, relay drop. Built incrementally based on symmetric keys with each OR. Circuits can be shared by many TCP streams. OPs build a new circuit periodically if the previous ones are used. Old circuits expire with no more open streams. OPs consider rotating to a new circuit once a minute. After a circuit is established relay cells can be sent. 8

9 Alice Bob and Carol 9

10 Other features Streams are opened with a relay begin and relay connected cell pair exchanged between OP and OR Closing a stream can be done Application asks to connect via TCP to a host and port. Application and OP communicate via SOCKS OP uses the newest open circuit. Normally with a relay end cell pair. Abnormally with a relay teardown cell Integrity is checked at the edges thanks to TLS connections The first four bytes of a SHA-1 current digest are sent with every relay cell Contents of all relay cells are added to the digest. A bad hash tears down the circuit. Bandwidth usage is limited with a token bucket approach Only incoming traffic is limited since Tor outputs the same amount of bytes as it takes in. Congestion control is still an issue if an OR/OR connection is used in many circuits A packaging window for connections to the OP and a delivery window for outbound connections. Every datacell decreases the window and every relay sendme cell received increases it. If the window reaches zero, all streams are no longer read. 10

11 Other features Puzzles against DoS Exit policies Directory Servers Computationally expensive to produce to keep clients busy while accepting TLS connections Avoid exit servers to be implicated in abuses. Public perception as a security requirement. ORs could also append information saying this went through an anonymity service. To track changes in topology, node estate, keys and exit policies. Only recognized ORs are added. Redundant and synchronized to agree on a common directory (threshold consensus). 11

12 Rendezvous points Access control Basic component for location-hidden services (aka responder anonymity) Work together with Introduction Points Together they protect a service from distributed DoS attacks. Authorization tokens add selective access for high-priority users. Options: Future schedule of unadvertised IP or secret public keys for the lookup service. Location-hidden services use a virtual TLD called.onion AuthorizationCookie.PublicKeyHash.onion Filter incoming requests to avoid attack by flooding. Robustness Should remain anoymous in the long term, not tied to a single router. Smear-resistance Illegal or disreputable services shouldn t be possible to be created by the attacker Application transparency Applications should not be modified to access location-hidden servers. 12

13 Hidden services Bob chooses and advertises some IP Each IP has its own circuit and waits for requests Alice picks a RP from which to connect to any of Bob s IP Alice sends an encrypted request. If Bob wants to talk to Alice he builds a circuit. 13

14 Advantages (over 1 st Gen Onion Routing) Perfect forward secrecy Separation of protocol cleaning from anonymity. No mixing, padding, or traffic shaping (yet) Many TCP streams can share one circuit Leaky-pipe circuit topology Instead of one onion per circuit, keys are negotiated with each hop (telescoping) A standard proxy interface for all applications (SOCKS) + application level proxies (Privoxy) To costly yet ineffective against realistic adversaries. Less public key operations. Better for anonymity. Can direct traffic in the middle of and off a circuit. Frustrates traffic and volumen shape attacks. Congestion control Directory servers Variable exit policies End-to-end integrity checking Rendezvous points and hidden services Descentralized, end-to-end acks to send less data until the congestion ceases. Trusted node distribute signed state information about known routers. Describe which hosts and ports can an exit node connect. Critical for confortable volunteering. No one in the circuit can change the cells content. No reply onions needed. Forward security achieved. 14

15 Attacks and Defenses Attack Observing user traffic patterns Observing user content Option distinguishability End-to-end time correlation End-to-end size correlation Website fingerprinting Defense Multiple streams Privoxy (filtering services) Avoid minority configurations Hide connection from OP to OR behind a firewall Leaky pipe topology Stream multiplexation Attack Defense Compromise TLS Keys Periodic key rotation Iterated compromise Circuit lifetime Run a recipient Privoxy Run an OP - DoS non-observed nodes Robustness Run a hostile OR Chances (m/n)^2 Introduce timing into messages Firewall Tagging attacks Integrity checks Replace content of unauhenticated authenticated protocols protocols Replay attacks Different negotiated session keys Smear attacks Exit policies and tolerance Signed releases, trusted directory, Distribute hostile don't trust if it doesn't come with code sources 15

16 More attacks! Attack 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 directories that a malfunctioning OR is working Defense Remaining half consensus, humans Majority vote Independence and attack resistence - - Test ORs Attack Make many introduction requests Attack an introduction point Compromise an introduction point Compromise a Rendezvous point Defense Authorization tokens, require computation Re advertisement, secret advertisement Close the circuit, test rendezvous requests Session key 16

17 Open Questions & Future Directions How often should user rotate to fresh circuits? How should we choose path lengths? Scalability Beyond a hundred servers Better directory distribution Incremental directory updates Further specification review What mechanism should be used to prevent adversaries from signing up colluded servers? How can clients perform discoveries while preventing attackers to exploit the gaps in their knowledge? How do we stop unreliable servers from making the network unusable? Bandwidth clases To avoid bottlenecks Incentives To participate in Tor, to limit abuse, not to use privacy systems Caching at exit nodes Improve anonymity, speed and cost. Cover traffic Is padding worth adding? Multisystem interoperability To work with MorphMix Wider-scale deployment What incentives are needed for clients to run their own OR? 17