TOR (The Onion Router) TOR (The Onion Router) is a free software implementation of second generation onion routing a system enabling its users to communicate anonymously on the Internet. Originally sponsored by the US Naval Research Laboratory, TOR became an Electronic Frontier Foundation (EFF) project in late 2004. The EFF supported TOR financially until November 2005, and continues to provide web hosting for the project. Like all current low latency anonymity networks, TOR is vulnerable to correlation attacks from attackers who can watch both ends of a user's connection. TOR implementations exist for Microsoft Windows, Apple Mac OS X, Linux, and other Unix variants. Description TOR is an anonymizing Internet proxy service designed to circumvent traffic analysis by proxying TCP traffic within chained, encrypted tunnels. Using this service, a client can disguise what resources (s)he is accessing on the Internet, thereby obfuscating any Internet activities, malicious or not. Analysis Many people believe there are legitimate usages for TOR, especially in cases where privacy is of concern. However, there are just as many, if not more, illegitimate uses as well. For example, attackers may use this service to hide the true source or destination of their connections, or an employee could bypass a corporate security policy in order to view prohibited web sites or use prohibited services like instant messaging without detection. What is even more concerning is the fact that various malicious codes can, once installed on an exploited host, establish hidden services on the host, such as web/file/ftp servers to allow for the creation of continuous malware distribution sites, should others be cleaned. Trigger Arbor, Peak Flow triggers an alert when the system identifies outbound TCP related traffic transmitted to known TOR servers. Affected Platforms and Versions Any Internet connected host running Windows, Linux, and/or Unix could potentially be affected. Malicious bots usually propagate automatically, scanning for unpatched vulnerabilities in popular network software and exploiting them to install malicious code on a host without the owner's knowledge. Alternatively, bots can propagate like a traditional Trojan horse or virus, tricking users into running malicious code (e.g., an e mail that contains a deceivingly named attachment).
Remediation N/A Workaround Blocking TOR simply by TCP port is difficult because a significant number of servers employ HTTPS (TCP port 443) for their TOR port, which is the primary port for connection forwarding. In addition, many servers employ TCP ports 9001, 9030, and 9050. Thus, blocking these ports can significantly hinder TOR operation. Blocking IP traffic to all known TOR servers is a more effective defense mechanism; however, the list of operational TOR servers changes periodically. As such, any firewall blacklist enumerating said servers will need to be updated accordingly. General References date organization title 2005 10 26 Electronic Frontier Foundation 2005 10 04 Electronic Frontier Foundation Tor: An anonymous Internet communication system Tor Abuse FAQ Anonymous outgoing connections Users of the TOR network run an onion proxy on their machine. This software connects out to TOR, periodically negotiating a virtual circuit through the TOR network. TOR employs cryptography in a layered manner (hence the onion analogy), ensuring perfect forward secrecy between routers. At the same time, the onion proxy software presents a SOCKS interface to its clients. SOCKS aware applications may be pointed at TOR, which then multiplexes the traffic through a TOR virtual circuit. Once inside the TOR network, the traffic is sent from router to router, ultimately reaching an exit node at which point the clear text packet is available and is forwarded on to its original destination. Viewed from the destination, the traffic appears to originate at the TOR exit node. TOR's application independence sets it apart from most other anonymity networks: it works at the TCP stream level. Applications commonly anonymised using TOR include: IRC, instant messaging and browsing the Web. When browsing the Web, TOR is often coupled with Privoxy a filtering proxy server that aims to add privacy at the application layer. Weaknesses DNS leaks As with many anonymous web surfing systems, direct DNS requests are usually still performed by many applications, without using the TOR proxy. Solutions such as the previously mentioned Privoxy or using the command 'torify' included with the TOR distribution are possible solutions to this problem. Additionally, applications using SOCKS5 which
supports name based proxy requests can route DNS requests through TOR, having lookups performed at the exit node and thus receiving the same anonymity as other TOR traffic. Traffic analysis Steven J. Murdoch and George Danezis from University of Cambridge presented an article, in the 2005 IEEE Symposium on Security and Privacy, Oakland, California, USA, May 8 11, 2005. They presented traffic analysis techniques that allow adversaries with only a partial view of the network to infer which nodes are being used to relay the anonymous streams and therefore greatly reduce the anonymity provided by TOR. They have also shown that otherwise unrelated streams can be linked back to the same initiator. Etiquette and abuse Because TOR is capable of anonymising arbitrary TCP traffic, it attracts its fair share of abuse. Routers maintain an exit policy of what traffic is and is not permitted to leave the TOR network through that node. Using a combination of addresses and ports, it is possible to combat most major abuses of the TOR network. Potential abuses include: Bandwidth hogging It is considered impolite to transfer massive amounts of data across the TOR network the onion routers are run by volunteers using their own bandwidth at their own cost. E mail Anonymous usage of SMTP (i.e., e mail) can result in spam. Consequently the default exit policy of TOR nodes rejects outgoing connections to port 25, the port used for SMTP. Anonymous hidden services Although TOR's most popular feature is its provision of anonymity to clients, it can also provide anonymity to servers. By using the TOR network, it is possible to host servers in such a way that their network location is unknown. In order to access a hidden service, TOR must also be used by the client. Hidden services are accessed through the TOR specific.onion pseudo top level domain. The TOR network understands this TLD and routes data anonymously to the hidden service. The hidden service then hands over to standard server software, which should be configured to listen only on non public interfaces. Services that are reachable through TOR hidden services and the public Internet are susceptible to correlation attacks, and consequently are not really hidden. An added advantage of TOR hidden services is that, because no public IP address is required, services may be hosted behind firewalls and NAT. As of 6.6.07, the 'hidden wiki', the only hidden service index site linked to from the World Wide Web appears to have gone down. As it provided an 'entry point' to the network of hidden services, and both the official TOR site and IRC channel seem reluctant to explain or indeed acknowledge the disappearance so far (or offer an alternative), this capability is rendered somewhat useless to TOR users who do not already have the address of a specific hidden service they want to visit.
Onion Routing University of Michigan, Department of LSAIT The following description assumes that the onion routing network runs on top of TCP [11], however it can be implemented on top of other protocols. The basic idea of onion routing can be traced back to a seminal paper on anonymous email by D. Chaum [1]. In this paper a system for anonymous e-mail communication is presented. It introduces a network consisting of a large number of "MIX" nodes. MIX nodes serve the simple role of accepting emails encrypted with their public keys, decrypting them, and then sending them on. Each node would also perform certain timing alteration of the emails, to make it harder for a network observer to trace the path that emails take. Because a node might wait an arbitrarily long time before forwarding the incoming email this system is primarily meant for non real-time communications. Onion Routing [8] provides a way for two parties - a connection initiator and a connection responder - to communicate with each other anonymously. Onion Routing protects its communications against traffic analysis attacks. It makes it very hard for network observers (such as crackers, companies, and governments) to reliably learn who is talking to whom and for what purpose, by examining data packets flowing over the network. It concentrates on hiding the source and destination of a packet, rather than the content of the packet. The content of the packet could of course be encrypted using any form of crytpography prior to sending. The system consists of a number of machines, called onion routers. Routers communicate with each other over TCP. Some routers also can serve as entry funnels, they can accept connections from the clients of the network. Some routers can server as exit funnels, they can create TCP connections leaving the network to the actual Internet services that are being accessed through the Onion Routing network. Such services can be world wide web, e-mail, peer-to-peer applications, etc. When a client application wishes to establish an anonymous connection to a server (such that neither the server, nor the network is able to associate the connection with the client), it first of all connects to an application proxy. An application proxy is, for example, a SOCKS proxy [3] that accepts protocol-specific connections from applications, and converts them into a generic protocol (such as a stripped down SOCKS protocol). The packets are then forwarded to an onion proxy. The onion proxy creates a route over the onion network and then constructs a special data structure, an onion. An onion is a multiply encrypted layered structure, with information about the route through the network being spread across the layers. The onion is then passed on to an entry funnel. When an entry funnel ( or any other onion router) receives an onion, it decrypts it, which reveals a layer containing information about the next hop in the route constructed by the onion proxy. This layer is then stripped off and the onion is forwarded on to this next hop. Eventually, the onion reaches an exit funnel. The decrypted packet is identical to the packet that was produced by the application proxy at the beginning of the connection. This packet will then be sent to the destination TCP host. Onion Routing relies on using Public Key Cryptography, which allows it to encrypt layers of onions such that only intended recipients of each layer can decrypt it with their private keys. Each hop along the route then only knows about the previous hop (that it received the onion from) and the next hop (that it was instructed to forward the onion to). Plus, as the entire onion is decrypted at each router, there is no correspondence on the data layer between an onion entering a router and an onion leaving the router. This means that an outside observer who sees the onion for a specific message enter a node does not know which of the onions leaving that node corresponds to that same message. If an eavesdropper compromises a host in the network of onion routers, they will only be able to see where the onion came from on the last hop, and where it should be sent to on the next hop. The absolute source and destination of the onion are hidden.
When the recipient sends a response to a particular message, the exit funnel converts it to the generic protocol, encrypts it with its own private key, and sends it backwards along the route: i.e. to the hop from which it received the corresponding incoming onion. Each hop then similarly encrypts the response onion with its private key and sends it backwards. Eventually the onion is going to arrive at the onion proxy, which will decrypt it with the public keys of the routers along the chosen route to get the clear-text data. A More Formal Description We will number all the routers in the network with numbers 1..N. Onion Router s has a public key Su and a private key Sr. The public key is well-known to onion proxies. Private keys are only known to the router. There also exists an encryption function E[key](data) and a decryption function D[key](data) with the property that data encrypted with a public key Su can be decrypted with the corresponding private key Sr, and vice versa. ie, D[Su](E[ Sr](data)) = data and D[Sr](E[Su](data)) = data. This is the basic premise of public-key cryptography. [5][6] When the first packet of a connection to be anonymised arrives at an onion proxy, the proxy constructs a random sequence of routers on the network it knows about, Zn*, e.g. <4, 3, 5>. Where the first router in the sequence is an entry funnel, and the last an exit funnel. Then, to send a packet of data to the exit funnel, it constructs an onion like so: E[4u](3's IP address, E[3u]( 5' s IP address, E[5u](data))). This onion is then given to the entry funnel (4). The entry funnel is able to decrypt the onion with its private key, revealing 3' s IP address and a chunk of encrypted data. It forwards this chunk to 3, and the process repeats. So, to retrieve the next hop in the route, a router first has to decrypt the onion with its own private key. Because no-one else knows this private key it is impossible for someone who intercepts the onion to extract the IP address for the next hop. Encrypting the entire onion for each hop is a big advantage, because now the onion looks completely different at each router and it is very hard to correlate it between nodes. To even further complicate traffic analysis, all onions are usually padded with random data before being sent, so that they are always of the same size.
This way, it is very easy to create a virtual onion circuit, much like virtual circuits in ATM. Simply sending an onion to a node K along a chosen path creates a virtual circuit along the path. To support these virtual circuits, an additional bit of functionality on the routers is required. Each router has a number of TCP links to other routers. Several circuits can be multiplexed over one TCP link. So, for each incoming onion, the router should be able to figure out which circuit the onion belongs to and then find out what outgoing TCP link the onion should be forwarded to. Once the network supports virtual circuits, two important benefits are provided. First, once a virtual circuit is created, the onions sent across the circuit need not include routing information. More importantly, data can travel back across the circuit in a secure manner. Here's how it works. In the example above, a circuit <4, 3, 5> would be established. Whenever an onion belonging to this circuit enters 4, it will be able to correctly forward it to 3. Moreover, when a response message enters 5, 5 will be able to associate this piece of data with the circuit and will know that the data should be forwarded to 3. To ensure data security, 5 first encrypts the piece of data with its own private key and then sends it to 3. 3 then encrypts it with its private key and sends it to 4. 4 does the same and sends it to the originating onion proxy. The onion proxy can then recover this data by decrypting as D[4u](D[3u](D[5u]( encrypted onion))) which will yield the original data that entered 5. Thus the circuit is bi-directional.
Some Advanced Considerations The system described above is the essential idea behind Onion Routing. Proper implementation (one of which will be discussed presently), however, must include a number of subtler details that are outside the scope of this overview. There are a large number of possible ways to attack Onion Routing systems: Denial of Service (DoS) attacks, disrupting the functioning of the system; traffic analysis attacks, decreasing the anonymity provided by the system; and many possible active attacks, where an attacker modifies the behaviour of the system (either on the TCP layer, or by controlling individual routers) to gain leverage in traffic analysis. Making Onion Routing secure is a research area that is currently active, with many different developments and results happening all the time. We will just outline the most important, frequently recognised techniques for increasing the system anonymity and security. Denial Of Service (DoS) Attacks Due to the open nature of the system, it is very easy to perform DoS attacks by, for example, forcing routers to perform a large number of cryptographic operations, or depleting their bandwidth resources. The best suggested way for protecting against that is by using some form of digital currency that clients must use to "pay" for routers' services. Such currency can be, for example, cryptographic puzzles (i.e. computations that are hard to perform but easy to verify) that are presented to clients. See [7] for an example. Passive Traffic Analysis The best protection against traffic analysis lies with obscuring traffic patterns. Making sure that all onions are of the same size, that timing information on circuits is obfuscated, and possibly adding noise traffic are all valid methods of protection against traffic analysis. Pipenet provides a very good model for counteracting traffic analysis attacks, however it is an idealistic measure, not attainable in real life. Active Traffic analysis This is the hardest to deal with. Active attacks can include corrupting or delaying traffic between onions to reveal circuit information, as well as setting up a large number of attacker-controlled routers. There are few effective measures against these attacks, however they are quite hard to perform in reality. Again, Pipenet provides an idealistic solution, that is not attainable in real life. Tor, An Implementation of Onion Routing Tor [2] is currently the most advanced implementation of Onion Routing in use today. Tor is currently deployed on the Internet.* Tor design is based on the Onion Routing design described above, however it differs in some implementation details. First important difference that Tor provides is perfect forward secrecy, which is defined by [9] as: disclosure of long-term secret keying material does not compromise the secrecy of the exchanged keys from earlier runs. The simple implementation with Public Key Infrastructure (PKI) we described above is vulnerable to traffic capturing. An attacker can record data going between routers, and can then compromise the routers at a later stage (to aquire their private keys) and thus decrypt the data. However, there are certain protocols that allow two
parties to establish a common "session" key, that is used to encrypt data and that is only valid for the duration of communications. Recorded communications then can not be decrypted. Tor uses Diffie-Hellman key exchange [10] between the onion proxy and each router along the chosen route to set up a set of encryption keys that are used to encrypt layers of onions for the duration of a circuits lifetime. PKI is still used, though, to ensure that the other side of an exchange is indeed who it claims to be. Tor also implements something called "leaky-pipe circuit topology". In the original Onion Routing protocol, only the last router in a route can act as the exit funnel. Tor changes the concept slightly, allowing any router along the route to be an exit funnel. This means that an attacker observing the end of a circuit will have a harder time figuring out where the traffic goes. A particular problem that we have not addressed above is distributing reliable router lists. Each onion proxy needs to have a fairly reliable list of routers on the network, along with their public keys and IP addresses. Tor provides special "directory servers", which are machines that active routers register with. Onion proxies can then query directory servers and get up-to-date lists of routers on the network. Directory servers also provide communal protection against attacks that involve setting up a large number of attacker-controlled routers. Each router operator needs to be approved by the directory server operator be listed on it, The original Onion Routing design only protected the identity of an initiator of a connection. The responder was presumed to be a TCP service with a well-known IP address. Thus the responder can be easily mapped to a person. Tor provides a service called "hidden services" which allows responders to be protected by the system. Further details on implementation of this feature can be found in [4]. These are the main improvements of Tor over initial Onion Routing design. Currently Tor is a very good implementation of Onion Routing, ready to be used to protect anonymity and privacy of online communications. * At time of writing, there are 60 high speed Tor nodes online. For more information see http://www.noreply.org/torrunning routers/. Conclusion Here we presented a protocol called Onion Routing. The purpose of Onion Routing is to protect the anonymity of a user who wants to communicate over a network. In particular, it will hide the destinations of all communications initiated by the user. Any outside observers will not be able to tell whom the user is communicating with and for how long. To achieve this goal, Onion Routing uses Public Key Encryption to put multiple layers of encryption around the original data packet, thus creating an object called an onion. This onion will follow a specific route through the network, and at each route a layer of encryption will be peeled off. Once the onion reaches its destination it will have been reduced to the original data packet. When a router decrypts the onion using its private key it will only get the address of the next router along the path. So no router will ever know the full path that is travelled by the onion. Since no outside observer will be able to follow an onion while it is travelling through the network, the communication is completely anonymous.
View of the Tor (Onion Routing) World Network QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture. On the left side you ll notice several different flags with names after them. These are the servers available to router traffic through. The flag represents the country the server is located and the name is the name of the server. Under the connection section you ll notice the server names traffic is being routed through. To the right of that section is the information about each server when clicked from the server listing. Here you can see where you are being routed.
View of Tor Client Control Panel QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture. In the Tor Status box you ll notice that the onion is green, which indicates that it is running. When Tor is off there will be a grayed out onion with a red X over top of it and it will be yellow when starting up. Located in the Vidalia Shortcuts box is the Stop Tor button. Once press the Tor connects will disconnect and Tor is no longer running.
References [1] D. Chaum, "Untraceable Electronic Mail, Return Addresses, and Digitial Pseudonyms", Communications of the ACM, Vol 24, No 2 (1981) [2] Tor: "An anonymous Internet communication system" - http://tor.eff.org/ [3] SOCKS Protocol v5: RFC 1928 - http://www.ietf.org/rfc/rfc1928.txt [4] R. Dingledine, N. Mathewson, P. Syverson, "Tor: The Second Generation Onion Router", Manuscript 2004 http://tor.eff.org/tor-design.pdf [5] OpenPGP Message Format http://www.ietf.org/rfc/rfc2440.txt [6] Public_key_cryptography http://en.wikipedia.org/wiki/public_key_cryptography [7] Hashcash - A Denial-of-Service Counter Measure Tool http://www.hashcash.org/ [8] M. Reed, P. Syverson, D. Goldschlag, "Anonymous Connections and Onion Routing", IEEE Symposium on Security and Privacy (1997) [9] W. Diffie, P. van Oorschot, M. Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography 2 (1992), 107-125. [10] W. Diffie and M.E. Hellman, New directions in cryptography, IEEE Transactions on Information Theory 22 (1976), 644-654. [11] Transmission Control Protocol - RFC793 - September 1981 http://www.ietf.org/rfc/rfc793.txt