Tor : The Second Generation Onion Router. Roger Dingledine , Nick Mathewson, Paul Syverson . Presented by Amruta P atwardhan. Original Onion Routing. Onion Routing is a overlay network that can anonymize TCP-based application like web browsing, Secure shell, instant messaging.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Tor : The Second Generation Onion Router Roger Dingledine , Nick Mathewson, Paul Syverson. Presented by AmrutaPatwardhan
Original Onion Routing • Onion Routing is a overlay network that can anonymize TCP-based application like web browsing, Secure shell, instant messaging. • In this network Clients decide which path to choose for routing and then build a circuit. • Each node in the circuit only knows it’s predecessor and the successor. • Because of many critical design and deployment issues this network was never implemented.
Tor : The Second Generation Onion Router • The Limitations of the Original Onion Routing was addressed in Tor - The Second Generation Onion Router by adding • Perfect Forward Secrecy – Uses incremental path building technique. • Separation of “Protocol Cleaning “ from anonymity – uses SOCKS as proxy interface. • Multiplexing of TCP Streams – improves efficiency and anonymity • Configurable exit policies – nodes can decide to which hosts and ports they want to connect. • Integrity Checking – hampers the attacks that include changing the data cell contents or connection requests. • Congestion Control – decentralized Congestion control uses end to end acks to maintain anonymity and let nodes at the edges detect the congestion . • Practical design for location-hidden services via rendezvous points. –provides responder anonymity • Directory Servers – trusted nodes act as directory servers and are downloaded by users periodically via HTTP.
Design Goals and Assumptions Goals and Assumptions: • Deployability – ease and inexpensive in implementation. • Usability –no modification required in the applications and can be implemented across all OS platform. • Flexibility – protocol design should be flexible and well specified for present and future work • Simple design -- protocol design and security should be user friendly
Design Goals and Assumptions Non –Goals or Weakness: • Not peer to peer: systems like Tarzan and MorphMix are defined for this. • Not secure against end to end attacks • No Protocol normalization -- Tor depends on other proxy filtering systems when using variable protocols like HTTP. • Not steganographic – Tor doesn’t hide who are connected on the network.
Design Goals and Assumptions Assumptions: • Tor does not protect against global passive adversary • Adversary can • Generate, modify, delay and delete traffic • Compromise many Onion routers • Operate Onion routers • Main aim of Tor design is to prevent the traffic analysis attacks than looking after the traffic confirmation attacks.
Tor Design All OR runs as normal user process with no special privileges. User runs local software Onion Proxy 1.Fetch directions 2. Establish circuit across the network 3.Handles connections from user application Accepts TCP streams & Multiplex them across the circuit OR1 OR2 TLS Connection • Maintains • Long term identity key – sign TLS certificates • -- sign OR’s router descriptor • -- sign directories • Short term Onion key -- decrypt requests from users to set up a circuit & negotiate ephemeral keys OR on the other side of the circuit connects to the requested destinations and relays data Router descriptor – a summary of it’s key, address bandwidth. Exit policy
Working of Tor • In Tor, OR communicates with each other and with OP’s using TLS connections and with perfect forward privacy. • Traffic passes along the connections in fixed cells. • Each Cell is of 512 bytes and divided into 2 parts • Header • Payload • Every header includes • circuit Identifiers : specify which circuit the cell refers to. • Command : describes what to do with the payload of the cell. • Depending upon the Commands the cell are divided into Control Cells and Relay Cells
Working of Tor Continued… • Control cell: • Interpreted by the nodes that receive them. • Used for Padding, Set up a new Circuit (Create), Tear down a Circuit(Destroy) 2 1 509 • Relay cell: • Carry Stream Data end to end. • Contains an additional header in front of the payload along with StreamID, checksum for integrity checking & length of the payload. • Uses different relay commands like relay data, begin, end, teardown, connected, extend, extended, sendme, drop 2 1 2 6 2 1 498
Circuit is built one hop at a time Alice Negotiates the keys with each Onion Router Messages are layered with every router encryption Working of Tor OR4 OR2 c2 C2 C3 c3 OR5 OR1 c1 OR3 C3 Port C1 C2 Tor Network
Working of Tor continued.. • Constructing a Circuit • Alice’s builds a circuit incrementally negotiating symmetric keys with each Onion Router one hop at a time. • Initially Alice sends a create cell with a circuit ID C1 to the first Onion Router in her chosen path. The payload of her cell has a 1st half of the Diffie-hellman handshake g^x1. • OR1 after receiving the request, reply's with a created cell cmd and g^yalong with a hash of negotiated key g^xy. • Once this circuit is established Alice and OR1 can send relay cells using the negotiated encryption keys. • If Alice wants to expand the circuit further, she will send a relay extend cell to OR1 containing the address of OR2 and encrypted g^x2 for OR2. • OR1 receiving the request will assigns new Circuit ID C2 and then forward it to OR2 using a create cell cmd • After OR2 responds created cell to OR1, OR1 send relay extended cell to Alice along with the payload from OR2 and the Key. • Now Alice and OR2 share a encryption key g^x2y2. • If Alice wants to extend the circuit further she continues the same process as above and telling the last node of the formed circuit to expand.
Working of Tor continued.. • After circuit Is established Alice can send relay cells. • When OR receives relay cell it decrypts with its session key for that circuit and checks for the valid Digest. If the digest is valid, it will accept that cell and then process it as directed . • If the digest is not valid, it will look for the circuit ID and OR of the next step and forwards the relay cell with the appropriate circuitID to the next OR. • To construct a relay cell for a particular OR, Alice encrypts the digest with the keys up to that OR. Since it is encrypted at different layers only targeted OR will have a meaningful value. • Because of this , leaky pipe circuit topology, Alice’s streams can exit the different OR’s on a single Circuit. • Later when the OR send the relay cell back to Alice, they encrypt the relay header and the payload using the key they share only with Alice. • All the OR’s in the path add their keys and then forward further till it reach Alice.
Working of Tor Continued… http://www.cs.wichita.edu/~jadliwala/CS898AB/classpapers/week3/tor-design.pdf
Working of Tor continued.. OPENING A STREAM • TCP Connections can be made using SOCKS. • OP chooses a suitable OR as the exit node and creates the circuit or uses the new already created open circuit. • OP then opens the stream by sending the relay begin cell. • After receiving the relay connected cell respond from the exit node to the OP, OP sends a SOCKS reply that the connection is successful • OP now starts accepting data from the applications TCP Streams and sends the relay data cells along the circuit to the exit node. • SOCKS – have a flaw that some applications can at times pass alphanumeric hostname or IP address to Tor Client. If DNS resolution is done then Alice reveals it’s identity to DNS server rather than sending through Tor Network. eg: Mozilla, SSH CLOSING A STREAM • Closing a Stream is analogous to closing a TCP connection. • If a stream closes normally , the nodes send relay end cell down the circuit. • If the stream ends abnormally, the adjacent node send the relay teardown cell.
Other Features • Integrity checking on Streams • Checks integrity only at the edges • Uses first four bytes of SHA-1 Digest with each relay cell • Computational overhead of computing SHA-1 is minimal. • Rate Limiting and Fairness • Uses Token Bucket approach
Other Features Congestion Control • Circuit Level Throttling: Keeps track of two windows: • Packaging window : Tracks the relay data cells the OR is allowed to send back to Onion proxy • Delivery Window :Tracks the relay data cell the OR is willing to deliver to TCP stream outside the network. • Whenever the relay data cell is packaged or delivered, their respective window is decremented. • If OR has reached the capacity of receiving the data cells it sends the relay sendmecell with streamID zero to OP • If OR receives this request, it will increase it’s packaging window • If Packaging window reaches 0, the OR stops accepting all the TCP connections on all the streams. . It will send the relay data cells only after receiving the relay sendme request. • Stream Level Throttling: Similar to the Circuit level Throttling but it also checks that the TCP stream is fully Flushed.
Other Features Rendezvous Points and Hidden Services • Rendezvous Points: Building points for location Hidden services. • Location Hidden services: Provide responder anonymity Main Goal of Location Hidden Services are • Access Control : to filter incoming traffic( helps in avoiding DDoS Attacks) • Robustness : maintains long term pseudonymous identity • Smear Resistance : Preventing the attacker from framing a rendezvous router and offering an illegal service and making the observer believe that it is the trusted router that has offered it. • Application Transparency : No change or modification in the application is required even if these services require access to special software.
RP Rendezvous Cookie Onion Router IP MSG IP Alice IP Bob Working of Rendezvous Point and Location Hidden Service
Other Design Decisions • Denial of service Attack • CPU consumption can cause these attacks • Crashing a Router can also cause a DoS Attack. • No defenses are implemented , but few solutions are suggested like • Solving a puzzle before accepting create cells or TLS requests • Limiting rates at which the cells or TLS connections are accepted. • Exit polices • Allows user to decide which node in a network will connect to which external hosts or ports
Other Design Decisions • Directory Servers • Trusted nodes act as directory servers • These directory servers act as Http servers that fetch state and router lists. • These lists are downloaded by users periodically • These directory servers combine this info with their own network and generate the signed directory list of entire network. • All the new nodes must be approved by the directory servers to prevent directory Server Attacks to some extent.
Attacks and defenses • Passive Attacks • Observing traffic patterns: -- Will reveal the user’s traffic patterns • Observing user content: -- Traffic is encrypted at user end but not at responder end. • Tor can use Privoxy or related filtering services . • Optional distinguishability: -- with this option, clients in minority are more likely lose their anonymity • different options available like rotate the circuits more often if concerned about linkability then those concerned about traceability • End-to-end timing correlation:--Attacker watching traffic patterns at the starting and the exit point of the network has greater chances of correlation. . • Defence against this is by hiding the relation between OP and the 1st Tor OR by running OP on Tor node or behind the Firewall. • End-to-end size correlation : packet counting at the starting and ending nodes can also correlate the traffic. • Leaky pipe topology can give limited protection. • Website fingerprinting – create a database of the fingerprints of file size and access patterns of the targeted websites. Not very effective against Tor, as it multiplexes streams in a same circuit.
Attacks and defenses • Active Attacks • Compromise keys:-- Compromised TLS session keys can see control cell and encrypted relay cells. • But to decrypt the those cells he need to have onion key .. So it is not possible to hijack an already established circuits. • Periodic rotation can limit this attack • Run a recipient: --If webserver is run by an adversary , it learns the timing patterns of the user. In case if the adversary also introduces the application protocol and program that let the initiator revel their information. • Tor depends on Privoxy or similar type of protocol to solve this problem. • Onion Proxy: -- assumed that the end users run their own OP • Tagging attacks – hostile cell can tag a cell by altering it. • Integrity check on cells prevent this attacks • Smear attack: An attacker can use Tor network for socially disapproved acts and eventually make the operators to shut down. • Exit policies reduce this type of attack to some extent. • Distribute hostile code-- trick users by making them use subverted Tor software. • Use only signed Tor releases with an official public key and check the directory entry for the latest secure version.
Attacks and defenses • Directory Attacks • Destroy Directory Servers – more than half directories are destroyed, directories will not have enough signatures for clients to use. Clients should manually decide whether to trust the resulting directory or not • Subvert a directory Server – Attacker can partially influence the final directory server • Subvert a majority of Directory Server – half or more than half Servers are compromised, the attacker can introduce as many as OR’s into the final Directory Server. • Encourage directory server dissent – A Protocol assumes that the directory Server operators agree on a set of directory servers. If a adversary can persuade an distrust in these operators, users are likely to be divided according to the directories they use.
Attacks and defenses • Introduction and Rendezvous Points Attacks • Make many introduction requests – Deny bob by flooding his IP with requests. • IP can block the request that lack authorization tokens. • Bob can restrict the request by introducing some computation for every request he receives • Attack an introduction Point – adversary can disable Bob’s IP. • Since IP has a n identity attached, it can re advertise itself. • The advertisements can be made secretly to only high-priority clients • Advertise different IP to different clients. • Compromise an Introduction Point -- Attacker can flood IP • Bob has to check his IP periodically . • If flooding is noticed he can close the circuit to that IP • Compromise an rendezvous Point – All the data is encrypted so it is not more sensitive that other OR’s
Open Questions • Open Questions in Low Latency Anonymity • How Often the User’s should rotate to the Fresh Circuits? • If done :– it is inefficient, expensive , intersection and predecessor attacks • If not done: -- user’s traffic is linkable • How should a User choose a path Length? • Randomly? • Even with this randomly chosen path as per our discussion, Adversary can predict using timing. • How end to end traffic attacks be resisted in both the low latency and High latency Systems? • Some approaches are • Wrapping control command in identical looking relay cells. • Link Padding
Future Directions • Scalability: - simple deployment and design, full network visibility model will not scale over few hundred servers. • Bandwidth Classes :-- All OR’s are assumed to have same bandwidth and latency • Incentives :-- should have better incentive structure for users those are participating in Tor. • Cover Traffic :-- currently Tor omits Cover traffic • Caching at exit nodes :-- to improve speed and BW exit nodes can run cache web proxy.But forward security is weakened. • Better directory distribution : -- As the state and Clients grow we need a better and scalable way to distribute up-to-date status of network