In previous articles: Part 1 and Part 2 we extensively used the Tor Browser Bundle that helps us ensure our anonymity. With the Tor Browser Bundle, we can easily start using Tor without installing and configuring any additional items. It also contains one very interesting project, a web browser that is based on Firefox and is specifically configured to protect our anonymity on the Internet. We won’t go into to much detail about features of the Tor Browser Bundle, but we will look at the specifically crafted features in the moderated Firefox web browser that protect us from giving away our identity. (For clarity, from now on we’ll refer to the moderated Firefox web browser simply as Firefox.) The Tor Browser Bundle contains the following components:
- Vidalia: A graphical user interface for Tor.
- Tor: A component that enables us to ensure anonymity for ourselves on the Internet.
- Mozilla Firefox: A web browser.
- Torbutton: Takes care of application level security so that Firefox doesn’t leak any security information.
We can also download the source code of the Tor Browser Bundle from here and build it ourselves.
Upon starting Firefox, the screen below appears:
The official Tor site recommends that we use the Torbutton as part of the Tor Browser Bundle and do not install the Torbutton ourselves as human error may result in incorrectly setting up Firefox. This could then lead to leaks in security and the release of private information. Torbutton used to be part of the Firefox plugins and we were able to install it manually but it has since been removed from the addons , which forces us to use it together with the Tor Browser Bundle.
Let’s look at the factors that could compromise the security of a Torbutton on the network. There are quite a few of them, presented below and summarized after :
1. Exit Node or Upstream Router
- In this scenario, an attacker runs an exit node in the Tor network, or controls the router that’s located between the exit node and the target machine. The attacker can then intercept requests/responses coming from the client to the server and changes them in order to disclose the user’s identity.
2. Ad Servers and/or Malicious Websites
- When an attacker controls the website that we’re trying to reach Obviously it can feed us anomalous responses that could compromise our anonymity.
3. Local Network/ISP/Upstream Router
- The danger here lies with an attacker who controls any router between the local network, through the ISP and to the target website. This can be dangerous if the user has Tor disabled because the attacker can then inject arbitrary code into the client connection. This is only probable when we’re enabling/disabling Tor on a constant basis, so the attacker can correlate between the Tor and non-Tor traffic and figure out our source IP address.
4. Physical Access
- When an attacker has physical access to the client machine, he or she can pretty much do anything arbitrary to the machine. This too can obviously lead to a loss of anonymity.
We can see that a user’s anonymity can easily be breached if an attacker can gain access to the local network, routers in between local networks, and ISP to a Tor’s entry node (or a Tor’s exit node to the target website) including the website itself. Please not that not every node is part of the Tor network. When we think about it, all of this makes sense. , Since all connections are encrypted, it is only the Tor network itself that is not vulnerable, Thus the attacker cannot inject malicious code in a response to our request.
Now let’s take a look how an attacker can compromise the anonymity of the end-user. First we need to assume that an attacker can inject an arbitrary response into our browser as described above. Possible attack vectors summarized below :
- A Firefox plugin that supports networking should obey browser proxy settings. But it can also disobey them and bypass these settings initiating the connection though the normal Internet without ever checking in with Tor. This bypass process reveals the client’s IP to the target website. If the plugin contains vulnerabilities, it’s also possible to exploit them, again, revealing the user’s identity.
- If an attacker can inject CSS, he can still convince the web browser to reveal the client’s external IP address through CSS popups, which are event handlers that fetch content via CSS’s onmouseover attribute. Now imagine that these popups are allowed to connect to the Internet and issue requests to the target website bypassing Tor.
Read and Insert Cookies
- If an attacker can get a cookie of an authenticated user, he can, of course, login as the user without too much fuss. This functionality should be prevented by the use of client certificates that would block the attackers from identifying themselves as an arbitrary user even if that same attacker somehow got his hands on relevant user cookies.
Create Arbitrary Cached Content
- A web browser can store a lot of information in its cache for quicker access to the resource when it’s needed again—some of which are also unique identifiers. Since the cache doesn’t have a same-origin policy, these entries can be read by any domain, thus revealing possible sensitive information to the attacker.
Fingerprint Users Based on Browser Attributes
- If an attacker can fingerprint the user’s web browser, he can get quite a lot of information from browser properties, which can uniquely identify the user. If the website remembers those settings it can reveal the user’s identity when visiting the target webpage normally or through Tor. This is possible because of many ways a user can configure their web browser to make it unique—the most common way of personalizing a web browser is the use of unique set of plugins.
Remotely or Locally Exploit Browser and/or OS
- An attacker can even exploit the web browser itself, the web browser plugin, or the operating system vulnerability, in order to gain access to the client machine. This results in a total compromise of the client’s system, which of course also reveals clients external IP address.
From all the above points, we can gather that a successful Torbutton component needs to hide any personal user information that can reveal the client’s identify. This can be accomplished by implementing the following features:
- The web browser must use the Tor proxy all the time and must not let any network enabled component bypass it and access the Internet in the normal way.
- All saved information that web browser saves for better user experience, like cookies, history, DOM, cache, etc, should be accessible only when used in the Tor-enabled state.
- All web pages that were accessed by the web browser must be restricted to performing the network activity only when in a Tor-enabled state.
- If the target website is fingerprinting the web browser used to access it, it can be a great feature to hide the presence of Tor. However, hiding the web browser used with its version number and installed plugins can help reduce the effectiveness of fingerprinting the web browser.
- Web browser should not write any Tor-related information on the hard drive, but should store it in memory until the user closes the web browser, at which point the browser should discard all data. This ensures persistent data isn’t left lying around on the hard drive even after the user is done visiting the web site.
- Web browser should prevent leaking any time zone information through the Tor network.
Anonymity Set Preservation
- Web browser should prevent leaking any information that can be fingerprinted to the target website (user agent, installed plugins, etc). This should prevent the target website from tracking users based on the fingerprinted data, which can be used to find out the actual client connecting to a website even when Tor is enabled.
- Web browser should block any unauthenticated updates and upgrades via Tor, since a malicious attacker can inject an updated malicious program to the browser.
We presented quite a few reasons why users utilized the Torbutton and immediately integrate Tor the Browser Bundle right into the Firefox web browser. It provides quite a few modifications that make our browsing experience more secure and anonymous. If we use Torbutton outside the Tor Browser Bundle, there’s a greater risk that the web browser will do something unexpected, which could compromise our anonymity.
We must also mention that the Torbutton is integrated into Firefox only, since it’s open source. Torbutton support for other web browsers like IE, Opera, Safari, etc is not available and it will never be.
Tor has a SOCKS proxy running at port 9050 that we can use to ensure anonymity in any traffic that is sent through the SOCKS proxy to the Tor network. But our application needs to have SOCKS proxy support, otherwise we can’t use it to access the Internet anonymously. But don’t despair yet! There is a solution to that problem. Even if a program doesn’t support SOCKS proxy server, or any proxy server for that matter, we can still ensure anonymity its Internet usage with the use of a torify program. Torify uses a program called tsocks that can send TCP connections through a SOCKS server. We can also directly use tsocks to achieve out goals as demonstrated below.
First we need to install tsocks if we don’t have it already. The following is a command to install tsocks on Ubuntu Linux distribution:
# apt-get install tsocks
If we’re installing tsocks on a Gentoo Linux distribution, then we first need to enable the tordns useflag, which allows DNS queries to be sent through Tor and eliminates the DNS leaking problem as described in part 2. To install tsocks on Gentoo, use the commands presented below:
# echo "net-proxy/tsocks tordns" >> /etc/portage/package.use
# emerge net-proxy/tsocks
Afterwards, we need to configure tsocks to use the Tor anonymity. We can do that by editing the /etc/tsocks.conf configuration file. At a bare minimum, the configuration file should contain the following lines:
local = 192.168.1.0/255.255.255.0
server = 127.0.0.1
server_type = 5
server_port = 9050
With this local configuration variable we can specify that this machine can directly access the specified network 192.168.1.0/24. The other configuration variables configure the host and port of the Tor SOCKS server and its type, which in this case is 5 (default is 4).
The command syntax of tordns is very simple and is taken from the Linux man page of tsocks:
> tsocks [application [application's arguments]]
> or tsocks [on|off]
> or tsocks
We can see that we need to specify the application we want to proxy through our Tor network. Note that only TCP packets will be routed through Tor; UDP packets will be routed normally, thus revealing our identitywe must watch out for that. We can quickly test this by accessing a certain file on our own Apache web server with a program like wget. First we need make the following changes on our server machine so that we can observe all access to Apache resources:
# tail -f /var/log/apache2/access.log
Afterwards we should download some resources normally (without tsocks) to confirm our IP address is displayed correctly. When we’re certain that is the case, we should also test tsocks to make sure that the IP is anonymous:
# tsocks wget http://www.server.com/image.png
In the access log we should observe an entry like the following:
220.127.116.11 - - [18/Jul/2012:00:33:25 +0200] "GET /image.png HTTP/1.0" 200 695 "-" "Wget/1.12 (linux-gnu)"
We can see that we requested the image.png from the IP address 18.104.22.168. To check whether the IP is indeed part of the Tor network, we can click on “View the Network” in the Vidalia GUI, which lists all nodes in the Tor network. Among those is also a node with the IP 22.214.171.124 as represented by the following picture:
We can see that the Tor node is located in Germany, has the IP of 126.96.36.199, and has been up for 48 days, etc. So, we’ve validated that the node is part of the Tor network, and thus tsocks works as expected.
 Torbutton Design Documentation, accessible on https://www.torproject.org/torbutton/en/design/.