Tor Write Up Final

Tor – The Second Generation Onion Router

Hidden Services Explored

12/19/10 TOR – THE 2ND GEN. ONION ROUTER

Page 2 of 23

1 TABLE OF CONTENTS

1 Table of Contents ........................................................................................................................................................... 2

2 Tor – The Second Generation Onion Router .................................................................................................................. 3

3 The Way it Works – simplified ....................................................................................................................................... 3

4 The way it works – Advanced......................................................................................................................................... 4

4.1.1 The Torrc File ................................................................................................................................................... 7

5 The Project ..................................................................................................................................................................... 7

5.1 The Hidden Services ............................................................................................................................................. 7

6 The Setup ....................................................................................................................................................................... 9

6.1 The Setup of the host Server................................................................................................................................ 9

6.1.1 Virtual machine access .................................................................................................................................. 11

6.2 The Setup of the Virtual Machines..................................................................................................................... 12

6.2.1 Authoritative Directory Server ...................................................................................................................... 12

6.2.2 Relays ............................................................................................................................................................ 13

6.2.3 Clients ............................................................................................................................................................ 14

6.2.4 Client Hidden Service .................................................................................................................................... 14

6.2.5 Accessing hidden services ............................................................................................................................. 15

6.2.6 Socks .............................................................................................................................................................. 15

6.2.7 Client and relay.............................................................................................................................................. 16

7 Control Port.................................................................................................................................................................. 16

7.1 ARM – anonymizing relay monitor .................................................................................................................... 19

8 The History ................................................................................................................................................................... 20

9 The real world .............................................................................................................................................................. 21

9.1 WikiLeaks ........................................................................................................................................................... 22

10 Works Cited ............................................................................................................................................................ 23


Page 3 of 23

2 TOR – THE SECOND GENERATION ONION ROUTER

In this lab, we explore in detail the components that make up Tor – The Second Generation Onion Router. We examine how anonymity is achieved, how anonymous the network actually is, build our very own Tor network in a slick test-style setup and then proceed to tinker with it. First though, before you begin to follow this report, it is essential to know how Tor (onion routing) works.

Note: From here on forth, we will interchangeably use the terms Tor and onion routing. When we refer to onion routing, we are talking about the current generation of onion routing (Tor) and not previous iterations of the program (generation 0 and 1).

3 THE WAY IT WORKS – SIMPLIFIED

ALICE SENDS A MESSAGE TO BOB. HOWEVER, NOBODY KNOWS THAT ALICE IS THE ONE WHO SENT

THE MESSAGE TO BOB AND BOB DOESN’T KNOW WHERE THE MESSAGE CAME FROM…

That is onion routing in a nutshell. As we are aware of how the internet works today; you send something to Bob

and it will take several different routers to get there. Send another thing to Bob and it will probably take the same

path. With onion routing, you can send something to Bob and it will take a random path to get there. When you

send something else to Bob, it will take a completely different path to get there. Each hop (onion router) in the

path it takes to get there is only aware of the ingress and egress hop; not one device knows the entire path of the

message. This is illustrated below, where the blue line is the path of communication number one and the red line is

the path of communication number two. It is also essential in creating anonymity to use at least 3 hops in the path.

Using any less would be a threat to your anonymity and using any more would significantly increase it.

Figure 1 - Example of Anonymity

This is just a basic explanation of how Tor and onion routing works. For a more detailed version, including the inner-workings of the Tor application, see the advanced version below.


Page 4 of 23

4 THE WAY IT WORKS – ADVANCED

This is a more detailed look at how the Tor application works to create anonymity and keep that anonymity strong and protect it from prying eyes. Before we can really understand Onion Routing, we must understand some Key things that make Onion Routing happen.

• Onion Router (OR) • Long-Term Keys (identity key) • Short-Term (Onion Key or ON) • Transport Layer Security (TLS) • Onion Proxy (OP) • Cells

o Control Cell o Relay Cell

Figure 2 - Message Encapsulated

Onion routing uses something called an Onion Router (OR), which is a node in the Tor network. It runs on each machine as a user-level process and each of these ORs maintain a TLS connection to each other. ORs also maintain two types of keys - a long term key and a short term key. Long term keys are used for 3 primary purposes: sign certificates, sign OR descriptors (such as summary of keys, bandwidth, exit policies, etc…) and to sign directories. Whereas the short term (onion) key is only used to decrypt requests from users to setup a circuit from host to OR, and is then used to negotiate a shared key for that connection.


Page 5 of 23

Onion routing also uses transport layer security (TLS) to establish a short-term key between the links when they communicate between ORs. These keys are rotated periodically so there is less of a chance of keys being compromised. Another feature that onion routing utilizes is an onion proxy (OP), which are often installed on the host’s local machine and is responsible for 3 primary things: to fetch directories, establish circuits across the network and handle connections from the user’s application(s).

One last interesting concept to understand about onion routing is the cell. A cell is defined as a connection from an OP-to-OR or an OR-to-OR. Each cell has a fixed-size of 512 bytes.

OP OR

OP/OR

OR OR

OR/OR

Figure 3 - Cell Connections

There are two different types of cells: a control cell and a relay cell. The control cell contains 2 headers and the payload (data). The circuit ID is used to specify which circuit the cell belongs to and commands tell it what to do with the payload. Based on these commands, cells are determined to be a control or relay cell. Some examples of the control cell commands are: padding (currently used for keep-alive, but also usable for link padding), create or created (used to setup a new circuit) and destroy (to tear down a circuit).

Figure 4 - Control Cell

The relay cell is almost identical to the control cell in terms of packet structure, but it has a relay header pre-pended before the payload. The relay header contains a stream ID (many streams can be multiplexed over a circuit), an end-to-end checksum for integrity checking, the length of the relay payload and a relay command. When we compare the amount of commands between a control cell and a relay cell, there are many more relay commands. Such as:

• relay data (for data flowing down the stream) • relay begin (to open a stream) • relay end (to close a stream cleanly) • relay teardown (to close a broken stream) • relay connected (to notify the OP that a relay begin has succeeded), • relay extend and relay extended (to extend the circuit by a hop, and to acknowledge), • And many more

Figure 5 - Relay Cell


Page 6 of 23

Now that you understand the terminology and concepts of onion routing, we can show how it all works together.

1. Alice will determine a random path to the destination. In this case the path is Alice-OR1-OR2-Website 2. Alice will obtain all the onion keys for all the ORs in the path from the directory server. 3. Alice will now send a Create cell to OR1 (the create cell will have a new CircID (CAOR1) and then the payload

will contain the first half of the Diffie-Hellman Handshake (��) encrypted with the onion key of OR1). Now OR1 is the only one that can open this packet.

4. OR1 now receives the packet and opens the packet with its onion key and sends a create cell back to Alice with a hash of the negotiated key (� � ��) and encrypts the message with its onion key. Alice will have no issue opening the packet because it has all the onion keys.

5. At this moment, we have established the connection from Alice to OR1. Now we have to extend the circuit further (Alice-OR1-OR2). So, Alice sends an extended relay cell to OR1 specifying the address of the next hop (OR2) and an encrypted (��) for OR2. This time the packet will be encrypted twice.

Now the packet will get to OR1, it will decrypt the packet and read the message (The message will say that forward the packet to OR2 and its address). OR1 will now copy the half-DH-handshake into a created cell and passes to OR2. It’s very important to understand that OR1 creates a new created cell with all new information, so to OR2 it seems like the packet was originated from OR1. OR2 now receives the message and decrypts it with her onion key and generates a shared key and then sends it back to OR1 in a created cell. OR1 sends the packet to Alice in an extended cell and now the circuit is extended all the way to the last node.

6. Alice Sends a relay begin cell to start the connection to the website. OR1 sends the request to OR2 and the TCP 3way handshake takes place. It’s very important to notice that the handshake is made by OR2 and not by Alice. Once the 3way handshake is completed, OR2 sends a relay connected cell to OR1 and OR1 back to Alice stating that the connection has been made to the website (also known as opening stream connection).

7. Closing stream connections can be done in two ways: abnormally and normally. Abnormally is if there are any errors and disturbance in the stream, the node closest to the host will send a relay message teardown cell and the circuit will be closed. Normally is when the exit node send a relay message end cell down the circuit and wait until it gets the first nodes own end cell message. The circuit is then closed.

Will be encrypted with OR2’s Onion Key

Will be encrypted with the shared key that was established between Alice and OR1

Figure 6 - Layer Keys


Page 7 of 23

4.1.1 THE TORRC FILE

The Tor application relies on one configuration file to get all its settings from, the Torrc file. The Torrc file contains each and every setting which is configured for that Tor process. You can customize the Torrc file to become an exit relay (where traffic leaves your node to the Internet), hidden services (which are explained further on), bandwidth limitations (what you offer the Tor network), and so on. It is quite a robust file with many options to fine-tune your Tor process to the way you like it.

5 THE PROJECT

As detailed in our proposal, this project was aimed to look at the way that Tor works, specifically in a private network setup, where it is not apart of the public Tor network. As well as, we wanted to setup a hidden service and then be able to try and un-earth its location using methods known to the Tor community.

The network was to be built using several machines; some PCs would act as relays, some would act as clients and one would act as the authoritative directory server for the network. In the end, it made most sense to have all of the machines be virtualized and ended up being so by installing the VMware ESX platform on one of the PCs in the lab. This machine would be running about 10+ virtual machines, so it had to be up to the task.

After the machines were up and running, the focus was shifted to Tor, where we would be setting up our own Tor network and testing the hidden services feature of Tor and seeing if we could exploit it.

5.1 THE HIDDEN SERVICES

Hidden services were introduced in Tor; the first generation of onion routing did not have such a feature. The basic idea of hidden services is that someone out there is hosting a service on the Tor network, and Eve or Warden cannot tell where it is actually being hosted. That’s the simple version.

The advanced version is as such…

Hidden services are used as a way for a server to hide its location on the internet. The server will be able to use services such as web publishing or possibly an anonymous internet messaging system. The IP address of the server will be unknown to anybody connecting to it. This is because the server information will be routed through the Tor network. There is one immediate dilemma we can see with this. How will anybody be able to access the server if it’s IP and location is hidden? In order to do this we use something called rendezvous points. A rendezvous point will be used to announce our hidden location to other users on the tor network. A hidden service connection is established in the following order using Bob as the hidden service and Alice as the connecting client:


Page 8 of 23

Figure 7 - Hidden Services Explained

1. Bob creates a long-term public key to identify his service (web, IRC, chat client, etc.)

2. Bob will randomly choose some introduction points. This descriptor will be advertised to the lookup service and will be signed with Bob’s private key

3. Bob’s descriptor will contain his onion address. This is a 16 character name that is derived from Bob’s public key

4. Bob will have to let Alice know of his onion address either via word of mouth or finding it on another website. She is not able to look it up via DNS or any other means

5. Alice now wants to connect to Bob so she will select a random rendezvous point (RP). Alice will create a one-time secret key to talk to the RP

6. Alice will get Bob’s public key from the descriptor (which lists one of Bob’s introduction points) that was posted earlier

7. Alice will then send an introduction message to one of Bob’s introduction points which tells Bob about Alice, her RP and the one-time secret for the RP. This message is encrypted with Bob’s public key. This is also the start of the Diffie-Hellman handshake

8. Bob will now build a circuit to Alice’s RP. He sends the one-time secret of the RP, the second half of the Diffie-Hellman handshake, and a hash of their session key

9. The RP will then connect Alice to Bob. The RP does not recognize Alice or Bob. The RP just acts as a relay between Alice and Bob

Note: There are now 6 relays in the path between Alice and Bob. Three relays are from Alice, including the RP. The other three Bob has chosen up to the RP

Directory Server

Introduction Point

Client

Hidden Service (HTTP, IRC)

Rendezvous Server

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

(Bob)

(Alice)

[9]


Page 9 of 23

6 THE SETUP

The setup was not as easy as it seems. There aren’t very many resources or documentation on how to configure your own private Tor network. It required several hours of research as well as a few trips to the official Tor IRC channel to speak with actual developers. In the end though, we persevered and had the network up and running.

We knew our goal and from speaking with members of the Tor community, we knew how many machines we would need to create our Tor network. (Note: Since Tor relies on anonymity, you need a certain amount of relays to provide this at all times – since using the same relay for each communication is not very anonymous).

We ended up planning 2 client machines – one to provide the hidden service and one to access it, 10 relays – to provide enough anonymity for the network as well as the hidden service and finally, one authoritative directory server (AS) – which would provide information about the network to everyone.

With this many machines needed, we knew it would not be viable to use physical hardware, so we planned from the get-go to use an all-virtual setup, which is explained in the next section.

6.1 THE SETUP OF THE HOST SERVER

For the project, we knew we were going with an all-virtual setup but it came down to which platform to use. We were deciding between VMware’s ESX platform and the Xen hypervisor. Both offered up the same types of features, also Xen is an open-source tool. We eventually decided to go with ESX, since VMware is usually the leader in virtualized products and because they offer a free license for it!

Installing the ESX platform went without a hitch; it was a pretty straight-forward install. It was decided that since we would be running so many VMs at the same time, some more memory would probably be a good idea. We borrowed 4GB from another machine and added it to our ESX server to boost it to 8GB total.

The installation of the first VM was completed; we used Ubuntu 10.10 as the operating system. The first VM would serve as the basis of all the other VMs. After we created the AS and perfected it in terms of programs, files, settings, etc…, it was suitable to begin cloning. We cloned the machine 12x to create every other VM and then made the necessary changes to each clone (IP address, hostname, etc) to make it unique. As well as basic settings, we did make some big changes to most of the machines, save two; we removed the GUI on all VMs other than Client1 and Relay10 so that we could save system resources. The reason these two machines were spared this action was for the use of a web browser to view the hidden service (requires GUI).


Page 10 of 23

Figure 8 - Overview of VMs and Resource Limiting

With each VM installed and ready to go, we had to implement the network structure. The ESX server itself had a connection to the Internet, which we would pass on to the first machine, the AS. The AS would have a public IP address via NAT through the ESX server’s global IP. This was done so that we could have access to the Internet in case we needed to update any existing programs or install new ones we had forgotten to. Using ESX, we created a ‘virtual switch’, which would allow us to network all of the VMs together. Doing this, we were then able to use the AS as a default route for each other machine; which would provide them access out to the Internet.

This was the final result of the topology of the VM network, including direct Internet access.

Figure 9 - Virtual Topology


Page 11 of 23

6.1.1 VIRTUAL MACHINE ACCESS

Accessing the VMs could be done in two ways – by using the ESX client or by using SSH.

Figure 10 - VM access

The ESX client is an application which is installed on a different machine other than the server (for example, a personal laptop or desktop). The client then has access to each VM through the use of a console. The console launches the VM into a window, where you can either use the GUI (if it has one) or command-line. Using it was nice and a breeze, but came with a drawback. There was no copy/paste integration with the ESX client’s machine, in this case, our laptop. This became tedious when trying to paste configs or copy them from the terminal. We combated this by implementing SSH. By installing SSH on each machine, we could then SSH login to the global IP of the ESX server, which was NAT’d to the first VM – the AS. From there, we could then SSH AGAIN into each and every other VM by using the public address space which we had setup. So, it was pretty much SSH’ing two-levels deep.

Funny: It was also a running joke at one point with the ESX client as well; the client only works in Windows, but we run Linux on our desktops. We created a virtual machine of XP on our everyday desktop and then used the ESX client to access the VMs off the ESX server. It was like a computer, within a computer, within a computer.


Page 12 of 23

6.2 THE SETUP OF THE VIRTUAL MACHINES

As mentioned earlier, each machine was installed with all the required applications. The more important applications being: Tor –alpha (developer version), SSH, Tcpdump and Wireshark. The majority of this section covers the actual setup of Tor on each machine and the differences in the Torrc file on each. Let’s start with the most important, the Directory Server.

6.2.1 AUTHORITATIVE DIRECTORY SERVER

Note: You may have noticed by this point, we have been using the word Authoritative Server (AS) and directory server interchangeably. They are the same.

The directory server needs to produce an identity key and a fingerprint key. These keys are what each other node (in this case, relays and clients) will need to have in their Torrc file so that they can communicate with the AS.

We generate the fingerprint by running the command ‘tor --list-fingerprint --DataDirectory /tor’ from the AS. We then create the identity key by running ‘tor-gencert --create-identity-key’ as well as using a password along this, which could be anything. We further modify the Torrc file to indicate that it is an AS (and not a client or relay). We end up with the following:

TestngTorNetwork 1 User Tor DataDirectory /tor/ RunAsDaemon 1 ConnLimit 200 Nickname authority1 ShutdownWaitLength 0 Log notice file /tor/notice.log Log debug file /tor/debug.log SocksPort 0 OrPort 3001 Address 192.168.10.10 DirPort 4001 AuthoritativeDirectory 1 V3AuthoritativeDirectory 1 ContactInfo [email protected] ExitPolicy reject *:* DirServer authority1 v3ident=IDENTITY OrPort=3001 no-v2 127.0.0.1:4001 FINGERPRINT

- Some of the administrative stuff; TestingTorNetwork set to 1 means that this is a private network and not a part of the public Tor network

- DataDirectory is the path where all the important Tor files are saved to

- SocksPort 0 means that no SOCKS connections can be made. We only want the clients to use this

- OrPort is where it will listen for other onion routers (OR)

- DirPort is which port to listen on for any directory servers – the authoritative directory server (AS)

- (V3)AuthoritativeDirectory is another setting to indicate that this machine IS the AS.

- Address is the IP of the machine - The ExitPolicy says not to reject any IPs and any

ports out. This is an AS so it shouldn’t be acting as an exit relay

- DirServer is the line which points to the directory server (AS) with the nickname and using its own identity key and fingerprint (which were generated before). Also, since this is the AS, it uses the localhost IP

Figure 11 - Directory Server's Torrc File


Page 13 of 23

We can see the output of the aforementioned DataDirectory server, where Tor outputs all its files

Figure 12 - Contents of DataDirectory folder

These files all provide the detailed description of the Tor network; they show the current onion routers, keys, certificates, log files and other important information.

6.2.2 RELAYS

Relays make up most of the private Tor network, which is necessary, since they are providing the anonymity for the clients.

TestngTorNetwork 1 User Tor DataDirectory /tor/ RunAsDaemon 1 ConnLimit 200 Nickname relay1 ShutdownWaitLength 0 Log notice file /tor/notice.log Log debug file /tor/debug.log SocksPort 0 OrPort 3001 Address 192.168.10.21 DirServer authority1 v3ident=IDENTITY OrPort=3001 no-v2 192.168.10.10:4001 FINGERPRINT

- Different Nickname than the AS; this is unique to each machine running Tor

- As well, a different IP Address is used for each machine’s Torrc file. If this isn’t specified, Tor will just use other means to figure out the address

- Again, the DirServer line points to the directory server’s (AS) IP using all of the AS’s information. V3identity, OrPort, DirPort and fingerprint

Figure 13 - Typical Relay Torrc File

The most interesting note about the relays is the access which they provide. Not see in the Torrc file for the relay is the exit policy. By default, if not specified, the default policy will be ‘accept *:*’. For example, the term ‘accept 192.168.1.1:*’ would allow any traffic to the host 192.168.1.1. Another example would be ‘accept 24.42.2.0/24:80’, which would only allow port-80 (web) traffic to the 24.42.2.0/24 subnet. This allows Tor node operators to specify where traffic can and cannot go. The option ‘reject’ could be used instead of ‘accept’ to create the opposite effect.


Page 14 of 23

6.2.3 CLIENTS

Finally, the clients’ configuration was as follows:

TestngTorNetwork 1 User Tor DataDirectory /tor/ RunAsDaemon 1 ConnLimit 200 Nickname client1 ShutdownWaitLength 0 Log notice file /tor/notice.log SocksPort 10001 ControlPort 9051 DirServer authority1 v3ident=IDENTITY OrPort=3001 no-v2 192.168.10.10:4001 FINGERPRINT HiddenServiceDir /home/tor/hidden_service/ HiddenServicePort 80 127.0.0.1:5222 HiddenServiceDir /home/tor/hidden_service_irc/ HiddenServicePort 6667 127.0.0.1:6667

- The SocksPort is now set so that applications can re-direct their proxy to that port

- The ControlPort was also set to 9051 to allow us access to the control port of Tor

- Same DirServer line as seen before; the client connects using the AS’s keys

- This client was the one setup to host the hidden service

- The Dir shows where to output the hidden service hostname and key

- The Port configures which port to redirect and to which address and port. In this case, we redirect port 80 to the local address on local port 5222

- We also setup IRC on port 6667 with a new hidden_service directory to produce a new .onion address

Figure 14 - Typical Client Torrc File

The difference between the each client’s Torrc files is the use of the HiddenService parameters. We could have set both to host their own hidden services, but since client 1 doesn’t use a GUI, it didn’t make much sense. A little more work was required to get the hidden service up and running however.

6.2.4 CLIENT HIDDEN SERVICE

When you set the path of the HiddenServiceDir in the Torrc file, it automatically creates the folder as well as two files. One is ‘private_key’ which is the new private key pair of the hidden service. The other is the ‘hostname’ file, which is the .onion address of the hidden service: Zmz3ermcc3ujbv4k.onion

So, what is actually hosted on the hidden service? For this, we used a basic HTTP server, thttpd.

Sidebar: Thttpd is a tiny, lightweight HTTP server which is recommended over the use of something like Apache, due to the fact that it doesn’t leak out any information. What this means, is that since you are running a hidden service, you want it to stay hidden. Something like Apache which due to its complexity, might have some sort of leak of information in its code, where it could compromise your anonymity (via an IP leak). That is why something like thttpd is recommended instead

We simply created a folder called ‘hidserv’ which is where we would store the hidden services files. We then ran thttpd and pointed it to that folder and made it use the local host address and bind it to port 5222 – ‘../thttpd –p 5222 –h localhost’.

With all of this preparation, the client on the other end should be able to access the index file we created in the ‘hidserv’ folder. To add to the data being sent and to prove it could be done, we also followed similar steps to get an IRC channel hosted on the same server. The same steps were followed to create a new hidden service folder which gives us a new .onion address.


Page 15 of 23

6.2.5 ACCESSING HIDDEN SERVICES

Now that the hidden service is up and running, we needed to test the access from the viewpoint of Alice – the client who wishes to view the hidden service. Since we had two different hidden services, a web site and an IRC channel, we required two Tor capable applications to view them.

The first, we used Firefox as the web browser with an extension created by the Tor development team called Torbutton. Torbutton allows Firefox to use a proxy service to mask the identity of the user and allow them access into the Tor network (with the correctly configured Torrc file).

Figure 15 - Torbutton Preferences

We used the SOCKS port that we had configured in the Torrc file with the localhost address serving as the proxy.

In terms of the IRC channel, it was a simple setup on the server end. Setting up the client to use Tor to access the channel was just as simple.

Certain programs come with built-in Tor support. One of these applications happens to be Pidgin, a very popular open-source instant-messaging program, which also has support for IRC. It was as simple and as easy as running the command torify pidgin and the application would run after having been prepared for Tor. Pidgin just required a few similar modifications as Torbutton; we specified the localhost proxy address and port and everything was up and running. The key point to using an application through Tor, is the use of a SOCKS proxy.

6.2.6 SOCKS

A SOCKS proxy is an Internet protocol that allows for routing of traffic between client and server. It works at layer 5 and is responsible for managing the connection between the client and the exit node of the Tor path. When traffic is sent from a client to a server a TCP connection is made to the SOCKS proxy and the proxy will talk to the destination server as opposed to the host machine.

Tor uses a SOCKS proxy on the connecting client. It is used so a client on the Tor network does not leak any IP information to the destination server it is trying to contact. The main thing to worry about is DNS information being leaked. In order to resolve hostnames your client needs to do a lookup to the server. This could possibly reveal your IP information. Tor must use a SOCKS proxy in order to properly route traffic through the Tor network. There are also many web pages that can reveal IP header information.


Page 16 of 23

6.2.7 CLIENT AND RELAY

For one part of the network setup, we thought it would be interesting to see what we could do if we setup a client/relay machine. That is, where one machine both acts as a relay for the Tor network and as well, has access to content on the Tor network (hidden services). We used Relay10 for this experiment. From reading what (Syverson & Øverlier, 2006) had to say in their document on revealing the true identity of a hidden server, we thought it would be interesting to attempt something along the same lines.

Using a client and relay on the same machine, we should be able to achieve some sort of timing attack where, if we were able to control the size of the path (number of hops) used to access the hidden service, we could with certainty, determine which address is that of the hidden service. There are certain modifications that would have to be made in the Tor source-code, to allow Tor to use a one-hop circuit, because by default (for the sake of anonymity) it does not allow this.

We were able to achieve this by commenting out some lines of code from a few files of the source code, but could not force the client to use one hop between itself and the rendezvous point. This would allow us with some effort and a little time, to see what the actual destination of the hidden service is. With the network all setup and running smoothly, we could not explore the many different aspects of it and how we can manipulate it.

7 CONTROL PORT

One of the more fascinating aspects of the Tor application is its built-in control port. The control port is used to configure many options while your Tor relay is running, as opposed to making changes to the Torrc file and restarting the Tor process. For instance, setting the parameter SocksPort 10001 in the Torrc file could also be achieved using the control port command ‘setconf socksport=10001’.

With the control port set to 9051 in the Torrc file, we can now launch Tor and telnet into the same localhost port. Once we connect we are now able to tune our Tor client on the fly.

Sidebar: It is useful to have something that can drastically change how our Tor relay or client is currently acting. With the control port we are able to dynamically tear down and create new circuits. The control port can also be used to monitor the bandwidth and many other options of the Tor relay.

In order to try and find the location of a hidden service we first wanted to be able to create our own circuits. We wanted to do this so we would be able to become the last hop to the hidden server. We can issue the command “getinfo circuit-status”. This will show us a list of current circuits the client has open.

14 BUILT $AC4273F54AF754FBFDAA77A09D5C9D09C9BF8C4E~relay10, $0831C92C30AD4A54840788C7264FAAD88CEA0A6C~relay2, $6EE3FC37E5AC09E8E366C8014C95474A47277E21~relay3

Figure 16 - Circuit Status


Page 17 of 23

In order to make it easier to find a hidden service we want to set relay10 as a one-hop only circuit. This will give us a better chance to locate the hidden service as we will be the only relay between the rendezvous point and the hidden service. By default, Tor will try and create at least a 3 hop circuit. So there will be three hops between the rendezvous point and the hidden service, and 3 hops between the client and rendezvous point. Having a 3 hop circuit on either side of the rendezvous point will make it much more difficult for us to introduce traffic to the Tor network and find out when we our relay is connected to the hidden server. To make this easier we can configure our relay as a 1 hop circuit. This way we can configure ourselves to be the only hop between the rendezvous point and the hidden server. Since Tor has a minimum default of 3 hops for each circuit we had to edit the source code of Tor to allow one-hop circuits.

Note: One-hop circuits are normally disabled because it would defeat the whole purpose of anonymity. Using one hop to get to your destination versus taking 3 or more – it’s clear which is more anonymous.

Once we edited the source code we needed to recompile to make Tor use our new changes. Tor is now able to build a 1 hop circuit through Relay10. Our goal now is to try and make Relay10 the final hop between the rendezvous and our hidden server. We first had to ensure that random paths were not being constantly built. These commands ensured that we had greater control over the circuits that are being built:

Now we need to create a one-hop circuit to the rendezvous. From the client machine we build a circuit making sure that we use relay10 as a middleman server. We need to act as a middleman so we can see the patterns in traffic going from the client to the hidden server. The following command is used to build the 1 hop circuit through relay10:

We have a circuit that runs through relay10 and are able to start introducing traffic to the hidden server. When we start a connection to the hidden server we can see on the control port the circuit that is being built between the rendezvous point and the client, as well as the circuit between the hidden server and rendezvous point. Looking at this capture from the control port’s telnet session, we can see the circuit that is being built to the rendezvous point, where HS_CLIENT_REND is the path to the rendezvous point.

Figure 18 - Creating our own circuit

extendcircuit 0 relay10

setconf __DisablePredictedCircuits=1 <- disable preemptively creating circuits

setconf MaxOnionsPending=0 <- maximum circuits pending

setconf newcircuitperiod=999999999 <- longer period before creating new circuit

setconf maxcircuitdirtiness=999999999 <- longer period for circuit expiration

Figure 17 - Controlling Tor's circuit building


Page 18 of 23

Looking at the information we can determine that the path to the rendezvous is setup as: client-Relay10-Relay2-Relay3. We would now know that our Relay10 is being used in the circuit to the hidden server. The control port telnet session will also show us the circuit that is built from the introduction point to the hidden server, where HS_CLIENT_INTRO is the path to the introduction point.

Unfortunately, for some reason we were not able to get the client to use a one-hop circuit. It kept creating the minimum 3-hop circuits. Also, our hidden service intro point made a 4-hop circuit. After trying many times to try and control these circuits to and from the rendezvous point, we were unsuccessful. We did some research and even talked to some of the developers on IRC again and learned that creating one-hop circuits when accessing a hidden server required a lot more coding knowledge. There are some options in the source files that would have to be edited. It was more than just editing the one file as we did before when just building one-hop circuits.

650 CIRC 142 BUILT

$6EE3FC37E5AC09E8E366C8014C95474A47277E21~relay3, $AC4273F54AF754FBFDAA77A09D5C9D09C9BF8C4E~relay10, $0BB04969EC2085357DAB09D3BCC1F48835FF2500~relay9, $0831C92C30AD4A54840788C7264FAAD88CEA0A6C~relay2 PURPOSE=HS_CLIENT_INTRO

650 CIRC 141 BUILT

$AC4273F54AF754FBFDAA77A09D5C9D09C9BF8C4E~relay10, $0831C92C30AD4A54840788C7264FAAD88CEA0A6C~relay2, $6EE3FC37E5AC09E8E366C8014C95474A47277E21~relay3 PURPOSE=HS_CLIENT_REND

Figure 19 - Circuit status

Figure 20 - Path to introduction point


Page 19 of 23

7.1 ARM – ANONYMIZING RELAY MONITOR

Sidebar: There was a program called ARM that we tried to implement into our private Tor network. However, there was a bug in the code that didn’t allow it to work within a private network. We talked to developers of ARM as well as some Tor developers but were unable to determine a solution to the problem; no work-around was found. This is a screenshot of it working on the public Tor network.

You are able to view your currently connected relays, both inbound and outbound.

Figure 21 - ARM, connected relays

We are also able to view the current network usage of our relay – both the upload and download usage. This would have helped to determine our timing attacks.

Figure 22 - ARM, bandwidth usage


Page 20 of 23

8 THE HISTORY

Onion routing’s roots can be dated back all the way to 1995. What started out as a volunteer project has evolved into one of the most widely used anonymous network overlays today. At the forefront of onion routing was the United States Navy. They were the ones who funded the research of the original (generation 0 and 1) onion routing; funded primarily by the ONR – Office of Naval Research. That year, the group came up with a lot of the foundation concepts of onion routing, which would later be evolved into what is used today, Tor.

Over the next few years, the group would continue to test and receive funding for development. They received further funding from a pretty prominent Internet group, DARPA. With this funding, they were able to fully develop the idea of hiding routing information, as well as making a leap from the standard onion key. They migrated to Diffie-Hellman keys, which would still be used in today’s version of Tor.

In 1998, the group began some bigger testing by building a network of 13 nodes, spread across the Naval Research Laboratory (NRL), the Naval Research and Development department and the University of Maryland. These were all under strict supervision by the developers. There were also two independent networks that were setup at external locations (one of which was the Canadian Ministry of Defense). From a purely technical view, at this point, they are still using a modified kernel to redirect all TCP traffic to the onion routing network. They achieved several targets in terms of testing the network, and all seemed to work well. However in 1999, there was a shortage of funding and further development of onion routing was suspended until 2001.

In 2001, DARPA continues funding the project to advance its development. The developers are now working towards getting the code up to par, to start running a full beta network (larger than was seen in 1998). A year later, some major changes were made to the project, as the code base was abandoned and work had begun on generation two of onion routing, what we know today as Tor (The Second Generation Onion Router).

Some of the bigger changes to the design include the adoption of a proxy system (Privoxy) that can be used for TCP applications, rather than developing their own proxy app. As well, this proxy application works in conjunction with SOCKS. With further funding from ONR, DARPA, the Tor network is further developed and finally launched in 2003, with about a dozen nodes being used (12 of which are from the US and one in Germany). This is the final step of the Navy’s part in this project, as in 2004, the funding almost completely ends from the Navy and the work is continued and overseen by the Tor project group, which receives funding from the EFF (Electronic Frontier Foundation). Tor was un-officially launched with the proceeding at the 2004 USENIX Security Symposium, with the paper – “Tor: The Second-Generation Onion Router”.

Today, development continues on the Tor project, which now runs as a non-for-profit US organization, which contains several employees and of course, thousands of volunteers around the world. It receives funding from all over the world, from companies with vested interest in the tool. News agencies, ISPs, Human Rights groups, even Google.


Page 21 of 23

9 THE REAL WORLD

One of the most fascinating realms of Tor is how it is actually used in the real world. The Internet is a big and scary place with a lot of information flying around at any given minute. Tor allows you to anonymously throw that information around. So, you begin to wonder, other than semester 6 telecom students, who is using Tor in the real world?

Political activists, dissidents, military officials, criminals and privacy advocates to name a few, are some of the people who would typically use Tor. It has been adopted by a plethora of people to use for the benefit of anonymity. In terms of rationale for using the Tor network, the range of good versus bad is quite great.

Tor has been known to be used by people who live in countries with Internet traffic laws. Countries such as China and Iran are two of the most famous. China uses a firewall to monitor and block any traffic originated within their country and trying to exit. This blocks activists who are against the totalitarian regime of China to get their voices heard by the rest of the free-speaking (mostly) world. A bit further west of China, there is Iran. Iran is an Islamic run state which basically is run by religion. They have very strict laws on a lot of things due to their religious views. During the recent protests of the 2010 elections, protesters were known to be using Tor to spread messages that were against the head of state, especially against the so-called, elected President Mahmoud Ahmadinejad.

One of the negatives to come from Tor is that because it is not discriminatory towards traffic, anyone can use it. Anyone can and does include criminals and people you generally wouldn’t like to be in the same room with. One of the worst users of the Tor network is said to be people with an interest in child pornography. As sickening as it sounds, the Tor network operators couldn’t do anything to weed these people out, since it would disrupt the anonymity of the entire network’s users. There was a man who did take a vested interest in this and caused a huge uproar with some Tor developers and user. HD Moore attempted to create a poisoned onion router, where using vulnerabilities in JavaScript, it would determine the location of a user (by IP address) who through a filtering system, would determine if they were using the Tor network for child pornography.

Well, besides activists, dissidents and criminals, Tor is utilized by officials as well. Tor has been known to be used by members of the government, military, police and any other agencies where privacy and anonymity is important to the safety of any individuals. Any road-warriors (agents who travel a lot) would be suitable to use Tor. They could communicate with the command centre without a prying-eye knowing where the traffic came from or where it’s going. It is also known to be used by the Pentagon (US DoD). That same information that the Pentagon sent over the Tor network was stolen by a pretty famous group, WikiLeaks.


Page 22 of 23

9.1 WIKILEAKS

WikiLeaks is perhaps the buzz word of 2010. They are the whistle-blowing group who is responsible for some of the biggest leaks of information we have seen since the days of the Pentagon Papers. Tor is a very beneficial network to the operators of WikiLeaks. There is quite an overlay between the two themselves, in terms of people and practice.

One of WikiLeaks’ first leaks was the result of data-theft on the Tor network. It is said that a Pentagon official was sending some sensitive information over the Tor network, and the exit node (where information leaves un-encrypted) was being run by a WikiLeaks members. The information was stolen and made public. That is the duty of WikiLeaks; take information that governments don’t think their population should know and bring it to the public’s eye.

WikiLeaks is run by the now (mostly) hated Julian Assange, an Australian hacker/journalist who wants people to know everything. He isn’t the only one working there. Another man, who many say was his right-hand man, is Jacob Applebaum. Applebaum was a speaker on behalf of Assange at several talks where Assange was too worried to make a public appearance. Applebaum also happens to be a core developer on the Tor Project. He is a huge advocate of all things private and anonymous – and leaked.

WikiLeaks actively uses the Tor network. When a member has some juicy information and cannot deliver it in person, they will usually transfer the data over the Tor network. This provides anonymity so that any government wire-tapper cannot figure out the source of the information. It’s quite ironic in the end.


Page 23 of 23

10 WORKS CITED

Dingledine, R., Syverson, P., & Mathewson, N. (2004). Tor: The Second-Generation Onion Router.

Johnson, D. (n.d.). ARM. Retrieved December 19, 2010, from Tor ARM Project Page: http://www.atagar.com/arm/

NAVY, U. (n.d.). Onion Routing: A Brief Selected History. Retrieved December 19, 2010, from Onion Routing: http://www.onion-router.net/

Rich, N. (2010, December 01). Meet the Most Dangerous Man in Cyberspace: The American Face of Wikileaks. Retrieved December 19, 2010, from Rolling Stone: http://www.rollingstone.com/culture/news/meet-the-american-hacker-behind-wikileaks-20101201

Syverson, P., & Øverlier, L. (2006). Locating Hidden Servers. IEEE Symposium on Security and Privacy .

The Sprawl: Tor Control Protocol. (2008, October). Retrieved December 19, 2010, from The Sprawl: http://www.thesprawl.org/memdump/?entry=8

Tor Project: About, Sponsors, Overview. (n.d.). Retrieved December 19, 2010, from Tor Project: http://www.torproject.org

Date post:	04-Jul-2015
Category:	Documents
Upload:	liquiddragon
View:	238 times
Download:	1 times

Tor Write Up Final

Documents