using onion-routing in well-established p2p networks to ......anonymity for purposes of anonymity,...

Technische Universitat Berlin

Using Onion Routing in Well-Established

P2P Networks to Provide Anonymity

DiplomarbeitBenjamin Michele

Technische Universitat BerlinFakultat IV - Institut fur Telekommunikationssysteme

FG Intelligente Netze

Aufgabenstellerin: Prof. Anja Feldmann, Ph. D.Betreuer: Gregor M. Maier

Abgabedatum: 20. Dezember 2008

Die selbstandige und eigenhandige Ausfertigung versichert an Eides statt

Berlin, den 20. September 2008Benjamin Michele

Abstract

Conventional approaches providing anonymous Internet access toend users rely on chains of proxy servers called Mix-nets [82], thatare based on a small set of static mixes. Some disadvantages ofthese approaches are, for example, weak resistance against blockingby government-level firewalls, poor scalability, and issues related totraffic analysis. The most well-known and established representativeof this class of systems is Tor [21]. On the other hand, there are a fewnew systems that try to circumvent these issues by using peer-to-peerapproaches, however, most of them lack a user base of sufficient size,which is vital for any anonymity system to work reliably.

In this thesis, The Anonymous Peer-to-Peer Proxy (Tap) is pre-sented, which addresses those issues. Tap builds on the design andknow-how of Tor, but brings it to the peer-to-peer world. Insteadof using a small set of dedicated servers to provide the anonymizingoverlay network, Tap uses all participating clients as servers as well.This approach is much more resistant to blocking due to the largeamount of daily changing nodes. The geographical diversity of nodeaddresses makes it more difficult for adversaries to observe all par-ticipating nodes and therefore impairs the ability to perform attacksbased on traffic analysis. Furthermore, it scales very well because eachadditional client also adds his own resources to the network.

To address the problem of a small user base in new systems, Tapis bundled with a popular peer-to-peer file-sharing client. As userstend to adopt new releases rapidly, a network with thousands of userscould be established within a few weeks. It also provides an excellentopportunity to replace Tor’s central directory servers, which are usedto locate Tor routers and their corresponding keys. Tap uses the file-sharing client’s mechanisms to get to know other nodes and the client’sdistributed hash table infrastructure to look up their respective keys.

CONTENTS

Contents

1 Introduction 1

1.1 Current Approaches and Their Shortcomings . . . . . . . . . . 1

1.2 The Anonymous Peer-to-Peer Proxy . . . . . . . . . . . . . . . 3

1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 5

2.1 Existing Circumvention Technologies . . . . . . . . . . . . . . 5

2.1.1 Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Chaumian Mix-nets . . . . . . . . . . . . . . . . . . . . 6

2.1.3 JAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 The Second-Generation Onion Router (Tor) . . . . . . 8

2.1.5 Peer-to-Peer Anonymization . . . . . . . . . . . . . . . 9

2.1.6 Alternative Approaches . . . . . . . . . . . . . . . . . . 10

2.2 Kademlia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 aMule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Public-Key Cryptography . . . . . . . . . . . . . . . . 12

2.4.2 Symmetric-Key Cryptography . . . . . . . . . . . . . . 13

2.5 HTTP Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Design 15

3.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Mode of Operation . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Starting the Tap Network . . . . . . . . . . . . . . . . 18

3.2.2 The Node Discovery Process . . . . . . . . . . . . . . . 19

3.2.3 Tunnel Establishment . . . . . . . . . . . . . . . . . . 20

3.2.4 Protection of Exit Nodes . . . . . . . . . . . . . . . . . 25

3.3 Censorship Resistance . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Current Censorship Methods . . . . . . . . . . . . . . . 27

3.3.2 Circumvention Approaches Used by Tap . . . . . . . . 28

3.4 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 A Single Adversary . . . . . . . . . . . . . . . . . . . . 29

3.4.2 Multiple Adversaries . . . . . . . . . . . . . . . . . . . 30

3.4.3 ISP or Government-Level Adversary . . . . . . . . . . 32

3.4.4 Attacks on the Lookup Service . . . . . . . . . . . . . 33

3.5 Implementation Details . . . . . . . . . . . . . . . . . . . . . . 33

iii

CONTENTS

4 Evaluation 354.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Testing Methodology . . . . . . . . . . . . . . . . . . . 364.1.2 Considerations . . . . . . . . . . . . . . . . . . . . . . 374.1.3 Performance Evaluation Tools . . . . . . . . . . . . . . 40

4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.1 General Comparison . . . . . . . . . . . . . . . . . . . 444.2.2 Load Duration of Initial Web Site Access . . . . . . . . 454.2.3 Load Duration of Subsequent Web Site Access . . . . . 484.2.4 Influence of Congested Nodes on Tap Performance . . . 484.2.5 Overhead Induced by Tap . . . . . . . . . . . . . . . . 504.2.6 Influence of Node Speed and Location on Tap Perfor-

mance . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.7 Analysis of Load Time . . . . . . . . . . . . . . . . . . 524.2.8 Tunnel Establishment . . . . . . . . . . . . . . . . . . 534.2.9 Influence of Object Size on Load Time . . . . . . . . . 534.2.10 Problems . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Conclusion 57

6 Appendix 596.1 Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.2 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 606.3 Deutsche Zusammenfassung . . . . . . . . . . . . . . . . . . . 61

iv

1 Introduction

“Everyone shall have the right to freedom of expression; this rightshall include freedom to seek, receive and impart information andideas of all kinds, regardless of frontiers, either orally, in writingor in print, in the form of art, or through any other media of hischoice.” [International Covenant on Civil and Political Rights,Article 19, Paragraph 2]

Freedom of speech is a human right recognized in a multitude of laws through-out the world. This includes the United Nations Human Rights Charter;its International Covenant on Civil and Political Rights has currently beensigned by 71 countries. The First Amendment to the Constitution of theUnited States is another example that “prohibits the congress to pass lawsthat would abridge freedom of speech or of the press”.

Freedom of speech is understood not only as the right to express butalso to seek and receive information and ideas, using whatever media suited.Obviously, this includes new media like the Internet as well.

This very right, however, is being attacked by various governments, In-ternet Service Providers (ISP), and others. Through censorship the rightto seek and receive information is being denied. Prosecution, imprisonment,commitment to mental hospitals [36, 69] and even murder [67, 4, 1, 14] of peo-ple for expressing their own views on the Internet aims at drowning freedomof speech. Coming to terms with the past, for example, plays an importantrole in society; however, this requires access to neutral sources. Many regimestend to censor information that may put them in a bad light, but all humansshould have the right to inform themselves on issues that are of interest tothem, e. g., their own and their country’s past, actions of their government,and so on. Suppression of freedom in forming one’s own opinion is dangerousfor society in general.

Various solutions have been proposed to overcome these restrictions offreedom of speech. To eliminate some of the shortcomings existing solutionshave, a new peer-to-peer based solution called The Anonymous Peer-to-PeerProxy (TAP) is proposed in this thesis.

1.1 Current Approaches and Their Shortcomings

Two main requirements must be met in building a framework that allowspeople to freely access and publish information. First of all, because accessto information may be blocked by ISP or government-level firewalls [20], mea-sures have to be taken to reliably transport user traffic through restrictive

1

1 INTRODUCTION

firewalls into a country with less restrictive information policies. From thefirewall’s point of view, this implies that the traffic must be indistinguishablefrom legitimate traffic. To protect the security of the communication initia-tor, details of the communication, such as final destination or content, mustnever be leaked to the firewall or their operators. This leads to the secondrequirement, namely the ability of a person to anonymously communicateover the Internet, i. e., the communication initiator can not be linked to thedestination. This also requires protecting the contents of the communicationfrom intermediate routers, which can be achieved by using encryption.

Some of the current solutions were designed to provide anonymity, oth-ers to circumvent censorship. Tor [21] is the most popular and widespreadsystem to provide anonymity. It was publicly deployed in 2003 and is nowused by hundreds of thousands of users [20] around the world. It has beenanalyzed by various experts and is constantly being improved. However, thedesign goal in mind when it was developed was anonymity and not censor-ship resistance. As more and more countries have begun to censor Internetcontent to their citizens, people have started to use Tor as a means of by-passing this censorship. An informal user study showed that about 20% ofthe people accessing the Tor network come from China [20]. Although Tor isnot yet being blocked by China’s firewall, this is likely to change in the nearfuture and could currently be done with very little effort [20]. However, Toris adapting to its users’ needs and is therefore actively searching for solutionsto circumvent a possible future blocking of its network. Although this thesisproposes a new system with a network parallel to the Tor network, it couldeasily be connected to the Tor network and aid Tor in being more resistantagainst being blocked.

Besides Tor, there are other solutions for anonymity and censorship resis-tance, but most of them either lack the ability to communicate in real-time,suffer from performance problems, offer an inadequate level of anonymity dueto a user base of insufficient size, or can easily be blocked by government-levelfirewalls. Section 2.1 will evaluate current systems in more detail.

Finally, the new approach presented in this thesis aims at closing this gap,offering a high performance, censorship-resistant, and scalable peer-to-peersolution for anonymous Internet access. In contrast to Tor, which supportsall SOCKS-aware TCP applications, the approach proposed in this thesiswill focus on Web browsing and therefore only support HTTP(S) traffic.However, applications that can be tunneled using HTTPS such as SSH [87]can also be used with the proposed system; Listing 2 on page 59 gives anexample.

In the rest of this thesis, the proposed solution will be referred to asThe Anonymous Peer-to-Peer Proxy (Tap), meaning a low-latency blocking-

2

1.2 The Anonymous Peer-to-Peer Proxy

resistant and anonymous peer-to-peer onion routing [34, 33] system.

1.2 The Anonymous Peer-to-Peer Proxy

Tap was developed with the following design goals in mind: anonymity, cen-sorship resistance, scalability, and usability.

Anonymity For purposes of anonymity, Tap’s design is based on Tor. Atunnel over multiple other Tap nodes is established and HTTP(S) traffic isforwarded using this tunnel. The tunnel is protected with a separate layer ofencryption for every tunnel node, so each node can only see what is requiredin order to forward the packet. This design is called onion routing [34, 33].Contrary to the Tor server network, Tap does not use fully meshed connec-tions to every participating node. Connections between the Tap nodes areestablished while the tunnel is built. This offers less protection from ad-versaries that are able to observe the access network, however, as Tap maychoose from a large pool of different IP addresses for tunnel nodes, chancesare that the observer will have no access to other nodes participating in thetunnel because they may be spread over the entire world and as well acrossdifferent autonomous systems [26].

New anonymity systems are always caught in a dilemma: “Anonymityloves company”[19]! This means that it is vital for an anonymity systemto have a user base of sufficient size at its disposal to hide users’ activitiesamongst activities of other users. On the other hand, if a (new) anonymitysystem cannot provide a sufficient level of anonymity, it will not attract newusers. Eventually the network will lose all its users and will be discontinued.To avoid this, Tap will be integrated to a popular peer-to-peer file-sharingclient. As users tend to use recent versions of the file-sharing client, thiswould create an initial Tap network of sufficient size to be useful. Then,while the network is gaining trust, it can attract more users.

Censorship Resistance Via the integrated Tap component, every useron the file-sharing network can provide his resources such as IP address andbandwidth to the Tap network and therefore offer an entry point to the Tapnetwork for other users. This way, a large number of daily changing IPaddresses would be available to the Tap network. Unless censors shut downtraffic to all dynamic IP addresses, it appears to be rather difficult to blockTap based on IP blacklists.

Two schemes for node discovery are proposed in this thesis, which aredescribed in Section 3.2.2.

3

1 INTRODUCTION

Scalability Using a peer-to-peer design gives the Tap network the abilityto grow as its number of users increases. Because every client of the ser-vice ideally also provides the service to others, the resources of the networkautomatically grow with the number of users.

Usability As mentioned above, a user base of sufficient size is crucial foranonymity. In order to convince a large user base to keep using the Tapnetwork, it is vital that it does not impair their surfing experience. Thismeans that the performance of the system, mainly in terms of latency, is veryimportant. The measurements conducted in this thesis show that tunnelsbuilt over regular broadband connections may definitely deliver satisfactoryperformance. Section 4 evaluates these measurements in detail.

1.3 Outline

Section 2 will describe existing solutions as well as provide background infor-mation on technologies used in the design of Tap. In Section 3 the design ofTap will be explained in detail. Then some results regarding Tap’s implemen-tation will be presented in Section 4. The performance of Tap will be eval-uated using different tunnel configurations in comparison to non-anonymousaccess. Tap’s performance will also be compared to Tor. The conclusionfollows, presenting ideas for future work and suggestions for improvements.

4

2 Background

In this section, existing anonymization technologies will be evaluated. Theirstrengths and deficiencies will be pointed out, which will eventually lead tothe current design of Tap as presented in this thesis. Then the technologiesthat are used in this thesis will be explained.

2.1 Existing Circumvention Technologies

The growing demand for anonymous communication has lead to a number ofdifferent approaches and designs. Starting with the simpler ones, this sectionends with Tor, being the most sophisticated.

2.1.1 Proxies

Figure 1: Proxy server

A Proxy is a server that acceptsrequests and forwards them in theserver’s name to their final destina-tion. By doing so, the origin of therequest is hidden. There are manydifferent kinds of proxies; however,the focus will lie on Web-proxies [83],i.e., proxies that are able to interpretand relay HTTP(S) traffic.

After receiving the response tothe initial request, the proxy forwards this response to the request initia-tor. Many companies use proxies for security and performance reasons toforward requests and cache Web server responses. Connections to proxyservers are generally unencrypted, connections from proxy servers to Webservers are always unencrypted. The exception to this rule is, of course,SSL encrypted traffic. Some very common proxies like squid and Apache’smod proxy even add a HTTP header field revealing the initiator by de-fault [24]. There are a couple of anonymous proxies on the Web, some ofthem do encrypt the connection between initiator and proxy. The mostprominent example is Anonymizer.com [40], which offers encrypted connec-tions to commercial proxy servers to protect a client’s privacy.

The security in terms of anonymity regarding a single proxy server is verypoor, even though the identity is hidden to the destination Web server andto routers between the Web server and the proxy. Every proxy operator iscapable of observing communication partners. Even worse, normally proxyconnections are logged. Additionally, proxy operators may easily eavesdrop

5

2 BACKGROUND

on connections that are not SSL encrypted. Thus breaking the anonymity ofa proxy is as easy as persuading or forcing the operator to reveal the log files.As for censorship resistance, only the address of a single or maybe a coupleproxies has to be blocked to render the service useless. Anonymizer.com triesto circumvent this by buying new IP addresses which are used for their proxyservers [22].

2.1.2 Chaumian Mix-nets

David Chaum introduced the so called Mix-net [7] system in 1981. A Mix-netis a chain of proxy or relay like servers. The sender identity is hidden to thereceiver by relaying messages through a chain of proxies. In order to keepthe proxies from reading the original content of the message and thus linkingsender to recipient, the messages are encrypted. The following example willconsider a chain of 3 proxies; however, the length of the chain may be freelychosen.

First, the sender prepares the message for the last proxy in the chain, P3.He does so by adding an envelope to the message that tells proxy P3 where toforward the message. Then this message, including the destination address,is encrypted with the public key of proxy P3. The sender then continues toprepare the message for the proxy P2, which is one step in the chain beforeP3. He repeats the steps he has already done for the last proxy, i. e., he addsthe address of P3 to the encrypted message and then encrypts it anew withthe public key of P2. Finally, the sender repeats the previous steps also forP1, adding the address of P2 to the encrypted message and then encrypting itanew with the public key of P1. The result is a multiply encrypted messagethat contains routing instructions that can only be read by the respectiveproxy.

In order to protect the Mix-net from adversaries correlating incoming andoutgoing traffic, thus eventually correlating sender and receiver, every proxyin the chain mixes the incoming messages and permutes the order in whichmessages are relayed. So if messages m1, m2 and m3 arrived in this order,they may be forwarded for example in the order m2, m3 and m1. In order tohave enough messages available for permutation, a proxy is required to waitwith the delivery of a single message until sufficient messages have arrived.This also requires the messages to be of the same size. If they were not, itwould be easy for an adversary observing the Mix-net to distinguish them notby order, but by size. In general, the more connections a mix is permuting,the safer a single connection will be. Mix-nets are the basis for the majorityof today’s anonymity architectures.

However, depending on the number of messages to use for the permuta-

6


tion, the delay added may be infeasible for low-latency applications such asWeb browsing, SSH or instant messaging. That is the reason why low-latencyanonymity systems like Tor or Tap do not permute messages and accept thatan adversary observing the communication endpoints may correlate the traf-fic. These attacks are called timing attacks [65].

Mix-nets offer improved anonymity compared to single proxies. However,for an adversary with sufficient power, it is not difficult to break the system, ifthe Mix-net consists of a fixed, small set of mixes. An adversary could forcethe operators of the Mix-net to log and correlate incoming and outgoingmessages. Using the log files, an adversary could retrace the path everymessage took, thus linking origin to destination.

2.1.3 JAP

The AN.ON project of the University of Dresden developed the Java AnonProxy, now called JAP [70]. It is an implementation of Chaum’s Mix-netsand is mainly used in Germany. JAP uses a chain of mixes to hide theidentity of a client to any Web server or adversary observing network traffic.Browser requests are encrypted and passed along the chain until the requestis finally sent to the Web server. The response is sent back on the same chain,traveling in the reverse direction until it reaches the browser. This approachprovides anonymity by mixing the client’s traffic with other clients’ traffic.After being delayed, mixed, and forwarded, it is difficult for an adversary tocorrelate exit traffic to the initiating client.

One of the problems with this approach is that it does not scale verywell. As user numbers increase, the quality of service in terms of latency andthroughput decreases. Since this is a non-profit university project, there is nomoney to invest on better servers and higher bandwidth. Funding ended in2006 and so some of the original team members founded JonDos [32], whichcontinues the development of the software and offers a similar service calledJonDonym. Contrary to JAP, the JonDonym service has to be paid for. Thisenables the providers of the mixes to offer servers with higher bandwidthand processing capacity, which leads to lower latency and higher transferspeeds for the users. The mixes are operated by different providers, only thepayment and organization is handled by JonDos. This makes the mixes moreautonomous and offers more anonymity, as an adversary has to compromisemultiple independent systems. In 2003 the German BKA forced [29] theAN.ON project to implement a logging function into JAP that would log allconnections to a particular IP address. Exactly one data record was logged,which then had to be handed over to the police. Although the police actionswere later found to be illegal [30], anonymity was already compromised and

7

2 BACKGROUND

may have caused many users to lose their confidence in JAP [61]. JonDonymnow addresses this problem by using multiple independent providers, partlyacting from outside of Germany. This incident, however, clearly shows howweak an anonymity system can be if it is centrally controlled by a singleoperator.

JAP and JonDonym both lack efficient measures against government-levelblocking [31]. As the number of available mixes is very limited, it is easy forrestrictive countries or ISPs to block access to the mixes.

Another problem can generally be seen in anonymization services that re-quire payment. By being required to transfer money to JonDos, one might becreating links that could compromise the own identity. JonDos recommendspaying with paysafecard [23], a prepaid cash card that lets users pay securelyand anonymously on the Internet. The use of paysafe aims to eliminate anysort of correlation between payment and identity of the user. Although thismay work in Germany or Europe, this sort of payment does not seem to becommon in other countries. Besides, it would be easy to prohibit the sale ofthese prepaid cards. Payment in general may also keep a broad public fromusing the service, thus degrading anonymity.

2.1.4 The Second-Generation Onion Router (Tor)

Tor is the most popular anonymizing system used nowadays, being activelydeveloped by The Tor Project [56]. It offers a local proxy service that canrelay TCP connections from proxy-aware applications. There are tools thateven allow non proxy-aware applications to access Tor, e.g., Socat [60]. Torbehaves in many ways like JAP; for example, a kind of Mix-net scheme isused to provide anonymity. But while JAP uses a fixed chain of mixes chosenby the user that is kept throughout the entire session, the Tor user client,called onion proxy (OP), dynamically establishes so-called virtual circuits byusing a set of Tor routers, called onion routers (OR). Circuits are establishedin the background and can be used to relay user data for approx. ten minutes;after that, a new circuit is used. Tor uses a Diffie-Hellmann [21] key exchangeto establish secure connections between OP and ORs. As soon as the virtualcircuit is not used anymore, the common key is deleted. Even if an adversarymanages to log all packets, it would be impossible to decrypt their contentlater on. This property is called perfect forward secrecy [62].

Data is transported in fixed-size cells in order to offer some protectionfrom traffic analysis. Tor focuses on its low-latency property and becauseof that does not introduce artificial delays for mixing nor does it use covertraffic. It is still an open question as to which extent this could be changedto offer better resistance against traffic analysis.

8


The onion proxy uses central directory servers that provide informationabout available onion routers. This information includes server capacity, IPaddress, and public keys, which is needed to establish virtual circuits throughthe Tor network.

Tor’s design was primarily chosen to provide anonymity, but not to resistcensorship [21]. Many people, however, are currently using Tor very effec-tively to circumvent government-level censorship. But, due to the limitednumber of onion routers1 and directory servers, it would be easy for thecensors to block access to the Tor network based on IP blacklists. The Tordevelopers are aware of this and are currently searching for solutions [55]; arecently published draft also proposes schemes for a more blocking-resistantdesign [20].

2.1.5 Peer-to-Peer Anonymization

The following gives an overview of current peer-to-peer (P2P) approaches.They are divided into two main types, namely, anonymous file-sharing andlow-latency, multipurpose anonymization.

File-Sharing and Other High-Latency Networks The following anon-ymizing P2P systems are designed for anonymous file exchange and thereforedo not focus on providing low-latency properties. This makes these systemsunattractive for applications such as Web browsing, SSH, or Voice over IP.Freenet, Entropy, Ants, Waste, Share, Perfect Dark, Nodezilla, Stealthnet,Marabunta, Winny, and OFF are some examples for anonymous file-sharingsystems, an overview can be found in [76].

The Owner-Free Filing system, OFF, has a very interesting novel ap-proach to anonymous file-sharing. A file that is to be shared is divided intonumbers, more precisely 128kB blocks. These numbers are XORed with otherblocks from other files and then published to the network, being stored byother nodes. During this process, a construction plan is saved in the formof an URL. These blocks are nothing but random numbers as for themselvesthey have absolutely no meaning. It is the relation between numbers thatcarries information, not the numbers themselves. Because a number can beused to reconstruct various files, no one is able to determine for which filethe downloaded number will be used. Files can only be accessed by usingthe above mentioned URL. This means that OFF effectively provides a dis-tributed virtual hard drive, allowing access only to the person who generatedthe blocks. If this person chooses to share his URL, access to a file is granted

1by the time of writing approximately 1200 active onion routers were running [43]

9

2 BACKGROUND

to everyone knowing the URL. OFF is under very active development, offershigh performance and seems well suited to resist censorship and legal impli-cations. However, it is obviously not designed for low-latency Web browsing.

I2P and GNUnet are frameworks for the construction of secure and anony-mous P2P applications. I2P offers its own private network with anonymousWeb sites, that can only be reached from within the network itself. Fur-ther applications include anonymous file-sharing (Phex), blogs, and news-groups (Syndie). The primary application for GNUnet seems to be anony-mous censorship-resistant file-sharing.

Low-Latency Approaches Tarzan [28] is a general-purpose peer-to-peeranonymizer, that is able to anonymize arbitrary IP traffic. Just like Tor, itis based on Chaumian Mix-nets and therefore uses layered encryption andmulti-hop routing. Although appealing, providing an IP level anonymizerrequires root privileges and is not easily portable to other operating systems,which makes the system unattractive to a large user base. Unfortunately,the development of Tarzan seems to be discontinued. The available sourcecode, dated early 2003, is very experimental and according to the authorshas only been tested on FreeBSD; it could not be built on a current Linuxdistribution due to missing libraries. This leads to the conclusion, that thenetwork is dead.

MorphMix [58, 59] aims to provide a peer-to-peer based, anonymous HTTPanonymizer, much like Tap. The anonymization scheme is also similar toTap, i. e., it is based on Chaumian Mix-nets and uses layered encryption andmulti-hop routing. The big difference to Tap is MorphMix’ node discoverystrategy: Morphmix establishes a secure connection to one of its neighborsand then lets this neighbor choose the next node for the tunnel. This hasthe advantage that the connection initiator only needs to have knowledgeof a very small fraction of the network. To solve the problem of maliciousnodes choosing only other malicious nodes for the tunnel and thus creatingan entirely compromised tunnel, MorphMix introduces a collusion detectionmechanism. However, Tabriz and Borisov demonstrate in [68] that this mech-anism cannot prevent colluding adversaries from compromising anonymoustunnels. Apart from that, it seems that only a very early prototype was im-plemented and so it must be assumed that no publicly deployed MorphMixnetwork exists.

2.1.6 Alternative Approaches

Picidae [71] follows a different idea to circumvent censorship. A Picidae serveris a Web server that offers a form in which a user can enter an URL; these

10

2.2 Kademlia

servers are operated by volunteers. This URL is encrypted with JavaScriptand sent by the browser to the Picidae server. The server then fetches thecorresponding Web page, makes a screen shot of the page, adds links asimage maps, and sends the image back to the client. The client’s browserwill display the image and a user can navigate normally by using the imagemap. It works very fast and indeed almost no difference to normal Webbrowsing is noticed. The main advantage of Picidae is that no additionalsoftware is needed and that no configuration changes have to made. Theservice should therefore also be usable from Internet cafes.

Picidae, however, raises some security concerns, too. In terms of anonym-ity, a user has to ultimately trust the operator of the Picidae server, becausea single operator is able to link users to Web servers. Even more, as serversdo not seem to prove their identity using, e. g., certificates, firewalls couldredirect users to malicious Picidae servers.

If Picidae servers become blocked, users have to find new servers to use.This is done by word-of-mouth advertising; users must either know otherusers they can ask or they may send an email to the Picidae authors.

Picidae poses an improvement to simple proxy servers, because the entirecommunication between Web browser and Picidae server is scrambled anda user does not have to change a single setting; however, due to securityconcerns it is not suited neither for anonymity nor for large scale censorshipresistance as it does not offer any kind of secure node discovery.

2.2 Kademlia

Kademlia [49] is an implementation of a Distributed Hash Table (DHT), whichis widely used, especially by aMule [3], where it is called Kad [6]. A DHToffers a decentralized data store of key/value pairs. Kademlia’s special char-acteristic is that node addresses and keys share the same address space, inaMule’s implementation 128 bit. Each key/value pair is stored on hosts hav-ing a small distance to the key. Distance is defined as the result of the XORoperation between a key and a node, or a node and another node. Kademliaprovides only four operations:

• PING checks if a node is still alive

• FIND NODE looks for the k closest nodes to a given node address

• FIND VALUE searches for and returns the value belonging to a key ofa key/value pair

• STORE stores a key/value pair on a node close to the key

11

2 BACKGROUND

Knowledge of the network is spread over the participating nodes. A Kademlianode knows many nodes that are close, but only few distant nodes. Keys thatare close to the own node id are found quickly because the node has a goodknowledge of its neighbors. Distant keys are looked up by successively askingdistant nodes for other nodes that are closer to the searched key.

Many P2P systems have implemented [80] Kademlia to look up sourcesfor files. This makes them independent from a central indexing server, whichcan be a point of attack and a single point of failure.

2.3 aMule

AMule [3], the all-platform Mule, is a P2P client for the eDonkey network.It uses the same P2P network as the popular eMule [25] client and is gainingpopularity due to its ability to run on multiple platforms. AMule can searchfor nodes hosting files by using a server, as well as by using the KademliaDHT (named Kad). The Kad network is implemented with UDP packetsand is compatible to the original eMule implementation, thus enabling it totake advantage of the huge eMule network community.

2.4 Cryptography

Tap uses public key cryptography to establish secure connections betweennodes. During connection establishment, public-key cryptography is used,which is replaced by symmetric-key cryptography for subsequent data. Thisis much faster, uses less system resources and does not waste bandwidth.The library used for cryptography is Crypto++ [16], version 5.5.2.

2.4.1 Public-Key Cryptography

Public-key cryptography, also known as asymmetric cryptography, uses dif-ferent keys for encryption and decryption. In order to encrypt data, a pairof cryptographic keys has to be generated once, a public and a private key.The private key is kept secret and is used for decryption. The public keyis published and can be used by anyone who wants to send an encryptedmessage to the person owning the private key.

Another mode of operation is used for message signing. If a messageis signed with a private key, anyone in the possession of the correspondingpublic key can verify its origin and authenticity. Tap uses RSA cryptographyfor the tunnel setup.

12

2.5 HTTP Requests

2.4.2 Symmetric-Key Cryptography

For symmetric-key cryptography the same key is used for encryption anddecryption. This means that sender and recipient of an encrypted messageshare a secret. Tap uses the symmetric cipher AES [15] in CTR [46] mode toprotect messages between Tap nodes from eavesdroppers.

2.5 HTTP Requests

HTTP is a stateless protocol, that enables browsers to communicate withWeb servers. There exist two HTTP standards, 1.0 and 1.1, which are sup-ported by Tap. HTTPS connections are handled by Tap, as well. All modernWeb browsers use HTTP/1.1 for requests, but there are some Web serversthat still use the older HTTP/1.0. Also many tools and utilities make use ofHTTP/1.0.

HTTP/1.0 Using this protocol version a new connection has to be es-tablished for every request/response pair. If a Web page consists of manyembedded objects, the browser will have to establish not only one connectionfor the retrieval of the initial Web page, but also one for every other object.Since the establishment of a TCP connection normally requires a three wayhandshake, one round-trip-time is lost before the actual request can be sent.Obviously this is especially inefficient on connections that have large round-trip-times. After the connection is established, the request can be sent. Therequested document is put in the first line of the request, which could, e. g.,look like this:

GET /index.html HTTP/1.0

Additional lines form the header, which is completed by an empty line andthen may be followed by a message body.

HTTP/1.1 HTTP/1.1 behaves similar to HTTP/1.0, except that connec-tions are not closed after the response has been delivered. It is rather keptopen and used for subsequent requests and responses, thereby avoiding newconnection establishment overhead. This results in significant performancegains especially on bigger Web sites with many embedded objects. This holdstrue for a multitude of current Web sites on the Internet, as shown in Sec-tion 4. Interactive Web sites using AJAX should use persistent connectionsfor performance reasons, too. Modern Web browsers such as Mozilla’s Firefox3 use a maximum of 6 concurrent persistent connections per server [27].

13

2 BACKGROUND

HTTP/1.0 did not require user agents to include the hostname in therequest. The consequence was that every domain name needed a unique IPaddress. In order to support multiple domains to be hosted on a server witha single IP address, HTTP/1.1 requires the use of a header field containingthe hostname.

HTTPS The browser will establish a normal TCP connection to the des-tination Web server. After that, encryption details are negotiated and anencryption layer between TCP and HTTP is enabled. HTTP requests willthen be sent transparently using this encrypted layer; this includes the firstrequest, too.

HTTP(S) via Proxies A proxy parses incoming HTTP requests for thedestination hostname, establishes connections to these hostnames and trans-parently forwards messages between browser and Web server.

The aim of HTTPS, however, is to protect the contents of HTTP requestsand responses from anybody except the initiator and the final destination.Even the initial HTTP request must not be leaked to any outsider, not evento a proxy. But if a proxy cannot parse the HTTP request, it has no meansof knowing where to connect. Therefore the protocol specifies an extra stepfor HTTPS connections over proxies. If the browser wants to establish aHTTPS connection to a Web server, it sends a CONNECT request to theproxy containing the destination address. The proxy will then establish aconnection to the Web server. When the connection request completes, theproxy will send a confirmation message back to the browser. From then on,the browser will forward all HTTPS traffic as normal using this connection.The proxy cannot inspect any packets traveling through this connection, butis still able to forward them.

14

3 Design

For this thesis The Anonymous Peer-to-Peer Proxy (Tap) was designed, offer-ing low-latency, censorship-resistant, anonymous Internet access. Its designis based on Tor, although Tap’s prototype implementation still lacks manyof Tor’s advanced features. One of the main differences between the twoleading to more scalability and censorship resistance is Tap’s peer-to-peerarchitecture.

3.1 Usability

As Dingledine et al. point out in [19], usability is a crucial factor in buildingreliable anonymity systems. In order to stay anonymous, a user has to hidehis actions behind the actions of others. Anonymity cannot be achieved byoneself but only through collaboration: The more users, the better. Thismeans that every anonymity system has to attract users to the system andtake care that they will continue to use the system. User perception ofusability consists of many aspects, this thesis will consider the following three:

• Does the tool accomplish its purpose as expected?

• Does obtaining or setting up the tool pose burdens on the user?

• Does the tool impede user Internet experience?

Suitability Obviously a new anonymization service will only have a verysmall user base to start with. The set of users participating correctly2 iscalled an anonymity set [19]. If users do not participate correctly, not onlymay their own anonymity be compromised, but that of all users is at risk!Compromised users add no security to the system, as an adversary mayeasily exclude them from his analysis. Therefore care must be taken not onlythat users participate in the anonymity system, but that they participatecorrectly [19].

As previously mentioned, a small anonymity set makes the system un-attractive to further users because it may not provide sufficient anonymity.This leaves new systems with the bootstrap dilemma: A small user set resultsin poor anonymity, but to attract more users good anonymity is required.

2Imagine a PGP encrypted email conversation where Alice encrypts her mails correctly,but Bob responds unencrypted, with his mail program attaching the contents of previousmails. Alice is dependent on Bob’s acting correctly for the entire system to work asexpected.

15

3 DESIGN

To overcome this dilemma, which has led to the end of various anonymi-ty systems as mentioned in Section 2.1.5, this thesis proposes bundling Tapwith an application that is already widely deployed and whose users tend towork with the newest version available (see Section 3.2.1 for user statistics).Adding Tap’s functionality to a widely known P2P client such as aMule,provides a good opportunity to bootstrap a Tap network. With the releaseof a new aMule version including Tap, there could be a large user communityafter a short period of time, thus eliminating the bootstrap dilemma. Forreasons of simplicity, Tap is bundled with aMule and not with eMule. AMulehas the advantage of running on multiple platforms, which was important forthe prototype implementation. However, because eMule has a much biggeruser community, a second implementation should focus on integrating Tapin eMule.

Installation As it is desirable to attract as many users as possible, theuser base will not be comprised of only experienced computer users. Everyextra download, configuration file, or setting that has to be applied by usersmay scare them away. Setting up Tor used to be somewhat complicated buthas since evolved to require only a few steps for a successful setup. As Toranonymization works on the TCP layer, normalization of application data isoutsourced to other tools such as Privoxy [17] that also need to be configured.Another step includes configuring the browser to use the anonymizing system.This may already be too complicated for not so sophisticated users. Toraddresses this by providing extensive documentation, by directly referring tohelp instead of error messages, and by bundling all the needed tools [19].

In contrast, as Tap comes bundled with aMule, this thesis proposes lettingthe installer optionally configure browser privacy options as well as installinga preconfigured browser plugin such as FoxyProxy [41] to easily switch be-tween anonymous and non-anonymous Internet access. Supplementary to theconfiguration options of Tap integrated in aMule, a Web-based interface toTap is added that can be accessed through the browser by using the specialURL http://tap/. This enables users to easily control the Tap client andedit its configuration settings without having to manually touch configurationfiles.

Seamless Integration The performance tests with Tor have shown thatat some times it is almost impossible to use the system due to high latency.Figure 6 displays the load times for Google’s main Web page over a periodof five hours. It clearly shows that the response times may vary significantly.Although there are periods where the page loads very quickly, other periods

16

http://tap/

3.2 Mode of Operation

Figure 2: Google error message while performing a search with Tor enabled

reveal very bad response times. As explained later in Section 4.2, the differentperiods correspond to different virtual circuits built over servers of varyingcapacity. The high variance in latency observed during some periods is mostlikely due to congestion on some of the onion routers. If users are unable touse or at least substantially impeded in using the Internet, they may turnaway from Tor, decreasing the possible anonymity set for the rest of the Torusers.

Tap works well regarding performance, as shown in Section 4. However,the future will show whether Tap can maintain the low latency when it isbeing actively used by a large community.

Sometimes Web sites can be blocked because the IP address of the Torrouter has been blacklisted due to abuse, as shown in Figure 2. Many ofthe Tor routers offering high bandwidth have static IPs. That implies that ablacklisted IP may block out users from certain Web sites for a long time.

Tap’s user base can be assumed to consist of users with a broadbandconnection or similar. The majority of these connections use dynamic IPaddresses that are usually changed at least every 24 hours. If someone’s IPwere blacklisted, he could easily regain unblocked access by reconnecting tothe Internet. Similarly, if an exit node were to be blacklisted, the user couldadvise Tap to use a different chain of relays immediately. Also, the chainsare rebuilt after a short period of time. This is a feature Tor and Tap havein common.


As a first step, Tap has to discover other nodes for relaying. This process isdescribed in Section 3.2.2. Then, after knowing a sufficient number of nodes,an anonymizing tunnel has to be built using a subset of these nodes. This isexplained in Section 3.2.3. The last step is to make the actual HTTP request

17

3 DESIGN

Figure 3: Tap overlay network

to a Web server (also shown in Section 3.2.3). Figure 3 depicts an anonymousconnection from a client node to a Web server using a tunnel through the Tapoverlay network. Finally, measures to protect exit nodes from being misusedby illegal activities are described in Section 3.2.4.

As Tap’s design has been inspired by the design of Tor, some of theapproaches are very similar. One of the main differences, however, is thatTor achieves anonymity by relaying many connections over a few well-knownservers, thereby hiding connections among others. Tap, on the other hand,relays only few connections per node, but uses a high number and diversityof possible nodes. This makes it more difficult for an adversary to observe allnodes [26]. Also, instead of hiding relayed traffic among that of other users,Tap tries to hide it using traffic from other applications. Although this hasnot yet been implemented, anonymous traffic could be relayed using dataconnections of the integrated file-sharing application. Future work has toshow whether this approach is feasible.

3.2.1 Starting the Tap Network

AMule as well as eMule have built-in statistics that show which softwareversion is being used by connected clients. These statistics clearly showthat the majority of the users on the eMule/aMule network use the latestclient software. During a sample session, from a total of 313 connected eMuleclients, approximately 60 percent were using the latest release of the software,version 0.49b. The statistics also show an estimated 2.5 million users on the

18


Kad network. Thus if a new version of the aMule/eMule software includingTap was released, many users would download and use the new release. Ifonly a small percentage of those users would activate the integrated Tapcomponent, the Tap network could start off with a large user base, avoidingthe bootstrap problem mentioned in Section 3.1.

3.2.2 The Node Discovery Process

Every distributed system needs some kind of discovery process to learn theaddresses of other nodes. Tor uses central directory servers that have a listof existing Tor routers, called onion routers (OR). A Tor client can query thedirectory servers for the list of all ORs and can then establish virtual circuitsover them. However, a powerful adversary may block access to all directoryservers and therefore render the service useless.

In contrast to Tor’s central directory servers, Tap uses decentralized meth-ods to locate other nodes. This has the advantage of better resistance againstgovernment-level or ISP-level blocking, as it does not offer any central pointof attack.

To adapt to the size of the Tap network, Tap provides two different meth-ods to locate other nodes for the establishment of anonymous tunnels. Thefirst method works even when there are only very few Tap nodes, but be-cause it is more vulnerable to blocking attacks, only the second method willbe used to discover other Tap nodes as soon as the Tap network has reacheda sufficient size.

Method 1: Node Discovery Using a Bootstrap File All Tap clientsoffer a dummy file, called bootstrap file, in the Kad network, i. e., their IPaddress is listed as a source for the file. In a second step, every Tap clientalso looks up sources for this file within the Kad network. Obviously, thesources returned are the addresses of other active Tap nodes. The maximumnumber of sources any Kad node can store for a given file is 300 [6]. If themaximum number of sources for a file is reached, an incoming new sourcereplaces the oldest source stored for that particular file. This means that bylooking up the sources for the bootstrap file, a Tap client can receive a listof 300 recently active Tap nodes. Subsequent lookups add further nodes tothe local list of known Tap nodes.

This lookup method is simple and reliable. The drawback, however, isthat it does not provide good blocking resistance, i. e., an adversary mayrepeatedly look up the list of sources for the bootstrap file and then misusethe results to build an IP blacklist used to block access to those IP addresses.As long as Tap is not considered a threat, this is not likely to happen [20].

19

3 DESIGN

But in the long run, an alternative method for node discovery is needed.The following paragraph describes a method more resistant to blocking thatwill be used as soon as a sufficient number of Tap nodes are available in thenetwork.

Method 2: Node Discovery Using Kad Messages Because Tap isincluded in the aMule application, it has access to the protocol messagesbeing exchanged between Kad nodes. An unused field in the header of thesemessages is modified by Tap to signal Tap’s presence to the recipient. Inother words, no additional messages need to be sent; the information is “pig-gybacked” onto messages that would have been sent by Kad anyway. On thereceiver side, this header field is evaluated by Tap. If the field shows thatthe sender uses Tap, the receiver adds the sender’s address to the local listof known Tap nodes.

Because there is no central list of participating nodes, this method hasthe advantage of being resistant to blocking. Furthermore, it works incon-spicuously and has no overhead. However, it can only work when Tap hasbeen enabled by a sufficient proportion of Kad nodes; if not, it is highlyimprobable for Tap nodes to receive Kad messages from other Tap nodes.

Thus, Tap will use the first method for node discovery in the beginning,when the Tap network is being started. Later, when a sufficient percentageof Tap nodes are available, Tap will switch to the second method and stopusing the first.

Key Retrieval In the second step, the list of known Tap nodes is aug-mented by their corresponding public keys. Whenever a Tap node enters thenetwork, it stores its own public key in the Kad directory. This can happeneither when a client is started up or when its public IP address changes. Abackground task continually tries to retrieve the keys of other Tap nodesfrom the directory and add them to the list of known Tap nodes.

3.2.3 Tunnel Establishment

Tap provides anonymity by forwarding user data through a chain of othernodes as shown in Figure 4. Tap runs on the local machine and offers a HTTPproxy service as well as a relay service on TCP ports. A local Internet browserthat is configured to use the proxy will connect to the proxy service port assoon as the user enters an URL of a Web site. This request makes Tapestablish an anonymous tunnel through a set of other Tap nodes. Currentlythis set consists of three nodes that are chosen randomly from the list ofknown Tap nodes that is created by the node discovery process explained in

20


Figure 4: Tap message forwarding scheme

Section 3.2.2. Tap connects directly to the first node in the chosen chain,which serves as an entry point into the Tap network and is therefore calledthe entry node. Using this connection, the tunnel is extended to the next hop,called an intermediary node. Finally the tunnel is completed by connectingthe last node, called the exit node, to the existing two-hop tunnel. SuccessiveHTTP messages may now be relayed through the established tunnel andthen be forwarded by the exit node to the destination Web server. Thefollowing paragraphs explain in detail the process of establishing a tunnel.Symmetric keys are only kept for the duration of the tunnel lifetime, whereasthe public/private key pair should be changed when the IP address of theTap client changes or at least every 24 hours. If the IP address changes, thepublic key has to be republished anyway because it is referenced in the DHTby the corresponding IP address. Better forward secrecy [62] can be achievedby frequently changing the public/private key pair. If packets are recordedby an adversary and later on the corresponding private key is compromised,only the portion of traffic belonging to this particular key can be decrypted.

Tunnel Establishment Packet After having chosen the participatingnodes, an individual random symmetric key is computed for each one of thenodes by the local Tap client. Because all browser TCP connections are mul-tiplexed using a single TCP connection, i. e., the Tap tunnel, every browserconnection has to be identified by a one byte identifier, called connId. Thisidentifier is added to the HTTP request packet that was received from theuser and the entire packet is then encrypted with the symmetric key for theexit node. A header, encrypted with the public key of the exit node, is added

21

3 DESIGN

En- p1 s1cryp- p2 s2tion p3 s3Field Length s1 n2 s2 n3 s3 n4 = 0 ConnId HTTP DataSize 2b 16b 6b 16b 6b 16b 6b 1b 1..1024b

Table 1: Tap tunnel establishment packet; si : symmetric key, pi : public key,ni : address of node i, ConnId : TCP connection identifier

that contains this symmetric key and a destination address of 0.0.0.0:0. Thisentire packet is then encrypted with the symmetric key of the intermediatenode and a new encrypted header is added. This header contains the IPaddress and port of the exit node, and is encrypted with the public key ofthe intermediate node. Finally, this packet is encrypted with the symmetrickey of the entry node and again an encrypted header is added, containingthe symmetric key and the address of the intermediate node. Algorithm 1shows this process in detail for a tunnel length of three nodes, i. e., entrynode, intermediary node, and exit node. The resulting packet is shown inTable 1, including the size in byte as well as the multiple layers of encryptionfor each field of the packet.

Connection Establishment Between Tunnel Nodes This encryptedpacket now carries all the information needed to rapidly set up the tunnel.The local Tap client tries to connect to the entry node; if it cannot connect,the entire node selection and encryption process starts anew. Discarding onlythe first node but keeping the rest of the chain poses a security risk, as anadversary could make Tap connect to nodes he controls by running Denialof Service (DoS) attacks against legitimate nodes. The same holds true forsubsequent hops; if one of the nodes is not reachable, the entire tunnel istorn down and recreated with a new set of nodes.

After successfully establishing a connection to the first hop, Tap forwardsthe encrypted packet. The receiving Tap node will try to decrypt the packetheader with its private key. If this fails, the connection is torn down. If theTap entry node was able to decrypt the packet header, it looks for the addressof the next hop in the header. It will then try to connect to this address. Ifthis succeeds, it will decrypt the message body with the symmetric key foundin the header and forward the packet after having adjusted the size header.

This process continues up to the last node in the chain, the exit node.After decrypting the header with its private key, the node recognizes that itis the exit node because the address for the next hop is zero. This means that

22


Algorithm 1: Generation of tunnel establishment packet

Input: HTTP request from Web browserOutput: Tap tunnel establishment packetbegin

connId← TCP connection identifier;packet← connId + HTTP data;tunnelLength← 3;allNodes← list of IP address/port tupels of all known nodes;tunnelNodes← choose tunnelLength random nodes from allNodes;for (i← tunnelLength down-to 1) do

nodei← tunnelNodes[i];si← generate symmetric key for nodei;encrypt packet with si;if (i = tunnelLength) then

header← si + 0;else

header← si + nodei+1;endencrypt header with nodei’s public key pi;packet← header + packet;

endlength← size of packet in bytes;packet← length + packet;return packet ;

end

23

3 DESIGN

the decrypted packet resembles the original HTTP request, plus a connectionidentifier. At this stage, the tunnel establishment process has been completedand the first request has already been transported to the exit node.

Proxy Behavior During Tunnel Setup For Tap to recognize that thetunnel setup was successful, the local Tap client must wait for a special con-firmation message sent back through the tunnel by the exit node. If duringtunnel setup this message is not received within a certain timeout, the tunnelis dropped and the tunnel creation process is started over with a different setof nodes. During the tunnel setup, new browser connections are discarded inthe prototype implementation for simplification reasons. Background estab-lishment of tunnels, as used by Tor [21], should be incorporated into futureTap implementations to provide smoother transitions while changing tunnels.

Connection Establishment Between Exit Node and Web ServerThe exit node will parse the request to get the final destination address.Tap currently supports plain HTTP/1.0, persistent HTTP/1.1 as well asSSL encrypted HTTPS connections, which are explained in Section 2.5. Be-cause the browser was talking to a proxy, the request header includes certainproxy-specific details. These details are changed by the exit node to consti-tute the header of a normal request and then the packet is forwarded to thedestination Web server.

Reverse Direction Upon receipt of the Web server response, the connec-tion identifier is added to the response packet. The exit node then relays thepacket back through the existing tunnel. To keep the other tunnel nodes aswell as intermediate Internet routers from reading the packet, it is encryptedwith the symmetric key of every node as it passes through the tunnel. Bythe time it arrives at the initiator, it has been encrypted with three differentsymmetric keys. The initiating Tap client decrypts the packet using the threesymmetric keys it had chosen while establishing the tunnel. After decryp-tion, the original response is forwarded to the browser port according to theembedded identifier.

Subsequent HTTP Requests Once established, an arbitrary number ofHTTP requests may be relayed using the tunnel; the data relay packet isshown in Table 2. HTTP requests are encrypted together with their corre-sponding browser connection identifier using the symmetric keys that werecreated during the tunnel setup. Each Tap node in the tunnel uses its sym-metric key to remove one layer of encryption and then forward the packet,

24


s1Encryption s2

s3Field Length ConnId HTTP DataSize 2b 1b 1..1024b

Table 2: Tap data relay packet; si : symmetric key, ni : address of node i,ConnId : TCP connection identifier

using the routing information from the initial tunnel establishment. Thetunnels are rebuilt every ten minutes, to keep adversaries from correlatingqueries made over the same tunnel.

3.2.4 Protection of Exit Nodes

Because of the anonymous nature of Tor, it has attracted not only personswith honest motives. Of course, a service of this kind also attracts criminals.This has consequences for the operators of Tor nodes, especially for thoseproviding exit nodes. First of all, measures must be taken to limit possiblemisuse as much as possible. Secondly, as not all misuse can be prevented,exit node providers must be protected from being held responsible for illegalactivities of other users. If an exit node was involved in accessing illegalcontent, its IP address may be logged by law enforcement agencies. Thismay lead to consequences such as confiscation of servers or home computers,house raids, and so on. Kai Billen’s Web site [5] lists some incidents in Ger-many in which servers of Tor exit node operators were seized by the police.Exit node operators must therefore be prepared to tolerate some “politicalheat”[22]. This may be the case for Tor exit node operators, but certainlynot all Tap users would be willing to accept the risk of having to convincelaw enforcement agencies of their innocence. Because as many persons aspossible need to be motivated to operate Tap nodes that relay connectionsof other users to Web servers, Tap’s misuse potential and thus the risk forthe (exit) node operators has to be minimized. The following lists some ap-proaches that prevent possible misuse of Tap as well as measures to protectexit node providers; however, only the last approach has been implementedin the prototype, yet.

Blacklists A blacklist containing domain names, IP addresses and URLscould be used to restrict outgoing traffic. It could be created by trustworthyNGOs that fight for freedom of speech, possibly in collaboration with lawenforcement agencies. These lists could then be signed and published in

25

3 DESIGN

the peer-to-peer network, in order to allow rapid and secure distribution.Every Tap user could then choose from a list of blacklists and use the onesappropriate for his needs. For example, a German user not wanting to comein conflict with the German police would choose a blacklist that had beenpublished by German authorities. In this way, the Tap node would still servecitizens in oppressed countries as a means of accessing information, but therisk of its being misused for criminal activities would be minimized. Thiswould also reduce the node operator’s risk of being wrongfully prosecuted.As these URLs could be considered confidential to the police, hash values ofthe URLs could be used instead of the URLs themselves.

Outgoing Port Restrictions Similar to Tor, Tap should allow restrictionof outgoing ports. For example, to reduce the amount of spam being sent overthe Tap network, outgoing connection requests to port 25 (SMTP) shouldbe discarded. Although Tap only forwards HTTP requests and not SMTP,an SMTP request can still be hidden in the HTTP header. Listing 1 onpage 59 shows a sample session using a university node as an exit node toanonymously send a mail over the university mail server. The mail serveronly allows this because, from its point of view, the mail originated locally.Some ISPs use their clients’ IP addresses to identify the clients as legitimateusers of the ISP’s mail server. A malicious Tap user could abuse this to sendspam [48].

Integration to Tor Tap could be extended to use Tor nodes as exit nodes.This way, Tap would still resist blocking, because the number of Tap entrynodes stays the same. However, Tap users’ IP addresses would not appearin Web server logs because Tor would be used for exit traffic to Web servers.Further research has to show if this approach is feasible.

Extra Header Indicating Tap Presence If Tap inserted an extra headerinto HTTP requests, law enforcement agencies observing illegal traffic mightnotice the header and would ignore these requests. However, this would beunlikely to happen and it would carry the risk of server operators blockingthese connections or returning different content [22].

Web Interface to Monitor HTTP Requests in Real Time In orderto give Tap users some control over what their client is doing, a Web interfaceis added that displays the last thousand HTTP requests that were relayedusing their client. To increase usability, future implementations should allow

26

3.3 Censorship Resistance

the possibility of directly selecting unwanted server addresses in the Webinterface and adding them to the URL blacklist.

3.3 Censorship Resistance

One of the main goals of Tap’s design is to provide censorship-resistant accessto the Internet. Tap differs from Tor in this point, as this was not initiallya goal of Tor’s design [21, 20]; Section 2.1.4 provides more details on Tor.However, current development of Tor is aiming in this direction [18, 20].

3.3.1 Current Censorship Methods

There are many ways for ISPs and governments to prohibit access to un-wanted Web sites. The following lists methods used by the “Great Firewallof China”, mainly taken from [88]:

• IP based filtering blocks traffic in the border gateways to and fromservers that are on a blacklist. This results in blocking not only of theintended domain, but also of all domains that happen to be hosted onthe same physical server, and thus IP address. This type of blockingcan be circumvented by using proxies, however, this has led in turn tothe blocking of numerous well-known proxies themselves.

• DNS servers may return false responses, redirecting to wrong Webservers or may not respond at all.

• URL-based filtering discards requests containing special keywords, e.g.,all URLs containing the word cache that are sent to Google are dis-carded, effectively disabling Google’s cache feature (which used to bea circumvention method to view some censored Web sites).

• HTML response pages are blocked based on lists containing prohibitedwords.

• If a page was blocked due to a keyword in a URL, access to this servermay be blocked for up to an hour [9]. Sometimes even the user’s entireInternet connection is blocked and may only be reactivated by restart-ing the computer or power-cycling the modem.

Technically, one way to block unwanted Web sites is to inject packets intothe data stream with the TCP reset flag set. This method is used by China’sfirewall; it sends reset packets to both TCP endpoints of the connection,i. e., the user and the Web server. Clayton et al. state in [9] that this

27

3 DESIGN

could be circumvented by a firewall that is set up to filter out reset packetson both endpoints of the connection; however, this does not have practicalrelevance [86] and should be avoided because it violates RFC 793 [53].

3.3.2 Circumvention Approaches Used by Tap

By using Tap, Internet users are able to circumvent the censorship an ISPor government may have imposed on them. Corresponding to the above-mentioned censorship methods currently used, the following lists counter-measures applied by Tap.

IP Based Blacklists To circumvent the country’s censoring firewall, anencrypted tunnel is established by Tap that leads out of the censoring country.From the point of view of the censors, an encrypted connection is made to amore or less random IP address that normally should not be on any blacklists.The main advantage of Tap’s peer-to-peer design over the client/server baseddesign of Tor is that it offers millions of potential IP addresses, most ofthem being changed after a maximum duration of 24 hours. Therefore Tapcan choose from a huge pool of changing IP addresses, which makes it verydifficult for censors to maintain IP blacklists. Although a censor could chooseto block traffic to all dynamic IP addresses, which would effectively blockaccess to the Tap network, it is improbable that this would happen becauseit would not only lock Tap out, but many other peer-to-peer applicationsas well. More efforts need to be made to hide Tap’s network fingerprint. Ifcensors were able to distinguish Tap traffic from other encrypted traffic, theywould be able to selectively block Tap. A solution could be to use aMule’sdata connections to transport Tap traffic, but this needs further research.

DNS Based Blocking With Tap, DNS requests are never made directlyfrom the originating machine, because this would leak information. It wouldalso be susceptible to DNS-based filtering as explained above. DNS requestsare forwarded through the tunnel and performed outside of the network beingcensored. Therefore, DNS-based filtering would have no effect.

URL Based Blocking Tap is resistant as far as URL and HTML responsekeyword filtering is concerned, because it uses encrypted connections betweenall the nodes participating in a tunnel. It is impossible to inspect the con-tents of the communication and therefore filtering can not take place. Onecountermeasure would be to generally prohibit the use of encrypted connec-tions. However, it is highly improbable that censoring countries would do

28

3.4 Anonymity

this, as it would stop any other kind of sensitive transactions such as onlinebanking and e-commerce, too.

3.4 Anonymity

Tap offers anonymous Internet access by relaying traffic over multiple relays.Each relay knows only its predecessor and its successor, but none of the othercommunication partners. It cannot even detect its own position in the chain,unless it is the exit node. Section 3.2 gives more insight to the details. Thefollowing will examine the anonymity properties of Tap regarding differenttypes of adversaries, also known as the threat model.

3.4.1 A Single Adversary

A single adversary is defined as an adversary that is able to monitor orcontrol traffic either on a Web server, or on any single node being used in aTap tunnel.

Hostile Web Server If an adversary operates or monitors a Web server, hewill only be able to observe connections from the exit node to the server. Thisleaves him without a clue as to who might be the originator of the request,unless, of course, the request itself includes identifying marks. For example,many webmail providers offer unencrypted access to their mailboxes, whichcan obviously compromise a user’s anonymity. Another threat comes fromcookies [44] that may be used to track users during and between Web sitevisits. Most modern browsers are able to selectively block them; Tap shouldinform the user to change the settings accordingly.

Single Compromised Tunnel Node If Tap uses an adversary’s node toparticipate in the tunnel, the following three cases could occur:

• The adversary controls the entry node. The adversary cannot tellwhether the connection on which the packet was received correspondsto the originator or to an intermediate node; neither is he able to readthe contents of the packet. This does not help the adversary at all.

• The adversary controls the intermediate node. He cannot distinguishbeing an entry node from being an intermediate node, so the aboveholds true for this case as well.

• The adversary controls the exit node. He can read and modify all thetraffic that is forwarded to the Web server, unless it is sent over a

29

3 DESIGN

HTTPS connection. This leaves the adversary with roughly the sameoptions as do running the Web server or monitoring the traffic betweenexit node and Web server, as previously discussed.

The Swedish security consultant Dan Egerstad demonstrated how easy it isto compromise Tor’s security if it is used incorrectly [39]. He set up severalTor exit nodes and monitored the unencrypted traffic. He was able to collecta thousand passwords to sensitive email accounts of governments, embassies,and NGOs. Except for Iran, officials did not respond to his warnings, so hechose to publish them on the Internet. Egerstad believes that many of thoseaccounts were compromised before and were being surveilled by someone else.This sort of attack could be used against Tap as well. It is highly probablethat Egerstand is not the only one performing this simple attack on the Tornetwork. A rapidly increasing number of Tor routers, e. g., in China, mayalso indicate the involvement of government circles [64].

To sum up, a single adversary will not be able to break the anonymity ofa Tap-protected user. However, as with Tor, it is crucial that no sensitivedata is sent unencrypted, because it is trivial for an adversary to monitorthe communication with the Web server. Web browsers do provide warningmessages to users about sending sensitive information unencrypted to theInternet; however, once disabled, they are mostly forgotten. A blacklist forpotentially compromising URLs could be used by Tap to inform users aboutpossible security risks if the URL was accessed.

3.4.2 Multiple Adversaries

The anonymity of Tap is compromised if a user builds a tunnel consistingcompletely of compromised nodes. As the nodes know who is connected towhom at any given time, it is trivial to reconstruct the chosen path betweenthe initiator and the Web server. However, considering that Tap may use anarbitrary number of relays, it can only be assumed that the Tap client usingthe malicious tunnel really is the initiator and not just another relay.

Traffic Analysis As long as at least one of the relays is not under theadversary’s control, the Tap user is protected. However, this does not taketraffic analysis attacks into account. If an adversary controls the entry nodeand either the exit node or the Web server, he is able to correlate trafficpatterns at both sides of the tunnel and may compromise the anonymityof the user. Adaptive padding as proposed by the authors of [65] could beincorporated into future Tap versions and offer some protection. Tap couldalso share data connections with the file-sharing application and thereby

30

3.4 Anonymity

blur incoming and outgoing traffic correlation. A third possibility would beto compress user data and then randomly add and remove padding.

Timing Attacks The authors of [52] present a timing attack against Torthat is based on the passive measurement of relay nodes. This attack couldalso be used against Tap. Making use of the fact that generating load on asystem will increase its latency for other streams as well, they set up a cor-rupt Web server and a corrupt node to measure latency with probe packets.While the response to a user request for a Web page on the server travelsback through the network, it increases the load on the corresponding nodesand thus the latency of the probes. By monitoring many Tor nodes at thesame time, it is possible to passively identify virtual circuits. Although the-oretically Tap is susceptible to this attack, it offers much better protectionthan Tor because there are too many Tap nodes to monitor at once and anadversary has knowledge of only a small subset of the existing nodes.

Node Distribution The more malicious nodes an adversary runs, thehigher the probability that a Tap client will elect only these malicious nodesfor the tunnel. The probability prelay,mal to choose a malicious node is thenumber of malicious nodes divided by the total number of nodes. The proba-bility ptunnel,mal to choose only malicious nodes for the tunnel is approximatelyp3

relay,mal, provided that the total number of nodes is sufficiently high and thetunnel length is three. This means that if there are 9000 independent nodesand an attacker manages to add an additional 1000 of his own maliciousnodes, every Tap user’s probability to choose his entire tunnel through threemalicious nodes is ptunnel,mal = ( 1000

10000)3 ⇒ 0.1%. What is interesting aboutthis is that if there are multiple individual adversaries trying to break theanonymity of Tap, they add anonymity to the network, as they add morerelays to the pool of possible relays.

Tap will treat multiple nodes with the same IP address but different portsas one single node. This way an adversary must use an individual IP addressfor every malicious node he wants to run.

Another protection measure is to use geographical information for theelection of nodes, i. e., Tap will use relays that are spread out over differentcountries. Ideally, the entry node would be in the same country as the Tapclient. Packets leaving the country would therefore not have the signature ofthe originator. Then the intermediary node would forward the packet to theexit node, which should be in the same country as the intermediate node.In this way, delays are kept small, as only one of the connections includedin the tunnel would have to cross country borders. But there is a security

31

3 DESIGN

problem to this approach: The entry node is able to tell that it is the entrynode, because it will forward packets to another country. This allows thenode to recognize that the host the packet came from must have been thetunnel initiator !

To avoid this, Tap adds more randomness, i.e., the intermediary nodemay or may not be in the same country as the connection initiator. In thisway the node sending packets across the country’s borders cannot tell if it isthe entry node or an intermediary node. Tap will also enable users to choosethe length of their tunnels, possibly even varying lengths during the samesessions. This way delays are still kept low and security is not impaired.

The current prototype implementation does not yet support the use ofgeographical information, nor can multiple instances of Tap using the sameIP address be treated as a single node.

3.4.3 ISP or Government-Level Adversary

The most powerful adversary is an ISP or a government. In repressiveregimes, ISPs are controlled by the government and therefore will be treatedas one and the same adversary. This type of adversary will be able not onlyto observe the network the client is connected to, he can control it!

This enables a new type of attack: faking the entire network from theclient point of view, i. e., providing an entire fake Kademlia overlay networkas well as corresponding Tap relays. The procedure would be the following:Tap connects to the fake overlay network, gets to know only fake Tap relayaddresses, looks up their public keys, and connects to those fake relays. Thisforces Tap to establish a tunnel over fake nodes, which therefore is in no wayanonymous. Although this attack is quite complex and has to be targeted toa specific client, it is nevertheless possible.

To provide some protection against such an attack, Tap should know ofsome trusted nodes. If the user suspects that the network is fake, Tap willcompare the public keys received from the possibly fake network to the keysreceived from a trusted node. If they are not identical, it can be assumed thatthe network is providing malicious nodes and the Tap user will be warned.

As previously mentioned, it is very important that the exit node is in adifferent country than the connection initiator, more precisely, in a countrywith uncensored, open Internet access. This has two advantages:

1. People living in countries that restrict and censor Internet access willbe able to access all Internet resources available in the exit node’scountry. In addition, they cannot be held responsible by their owncountry’s regimes for accessing those resources.

32

3.5 Implementation Details

2. Observation and prosecution is complicated greatly, as law enforcementagencies of different countries would have to work together to break theanonymity. This would also require a common view of the definitionof illegal activities in all participating countries. This may offer muchprotection to people only trying to express their views on their owngovernment or access resources on their own history, which might notbe in the interest of their own government. However, this would mostlikely not be considered a crime by the governments of other countries.This would make it difficult to convince the respective law enforcementagencies to collaborate. However, if the matter is considered a crimein both countries, law enforcement agencies are much more likely tocollaborate and try to break the anonymity.

As mentioned above, an adversary being able to monitor the entry node aswell as the exit node of an anonymous low-latency tunnel may compromise auser’s anonymity by analyzing the traffic [52, 65]. One of the steps Tap under-takes to prevent this is location diversity, meaning the previously mentionedregional spreading of relay nodes. However, current research [26] shows thatregional spreading may not be sufficient, because entry and exit nodes maystill lie within the control of the same autonomous system and may thereforestill be susceptible to timing attacks.

3.4.4 Attacks on the Lookup Service

A recently published paper [72] by Wang et al. describes multiple attacks onthe Kad implementation used by aMule and eMule. These attacks could beused to control the “dummy file” for the node lookup, but, as mentioned inSection 3.2.2, this method of node lookup is only used in the early stages ofthe network. The second method proposed for node lookup is not affectedby the attacks. The public key publishing process does not seem to be af-fected by these attacks, as they mainly focus on specific keywords (indexpoisoning) or specific nodes (back-pointer hijacking with Sybil attacks or re-flection attacks). More research, however, is needed to verify whether Tapin general would be affected by these or other possible attacks on the Kadimplementation.

3.5 Implementation Details

This section briefly summarizes some details of the Tap prototype implemen-tation. There are precompiled versions for Ubuntu (32 and 64 bit), as wellas a Microsoft Windows version; source code is also available [50].

33

3 DESIGN

The default length of the tunnel created by a Tap client is three; i. e., anentry node, an intermediary node, and an exit node. The current timeoutfor establishing a tunnel is three seconds; after that, three other nodes arerandomly selected and the tunnel establishment begins again.

The maximum size of user data sent by Tap is 1024 bytes per Tap message.If more user data is read from the socket, it is split into multiple messages.The maximum amount of data Tap will read from a socket and process in asingle run is limited to 8192 bytes. As Tap multiplexes multiple TCP streamsof a single user over one TCP connection, a one byte header identifying thestream is added to the message and encrypted. Additional two bytes areused to denote the length of a message. In order to not waste bandwidthdue to multiple small TCP/IP packets, Tap messages are buffered in theapplication and handed over to the TCP/IP stack as one packet. To forwarda Tap message from another node, Tap reads the first two bytes, the length ofthe incoming message. If the amount of available data is equal to the lengthset in the header, the message is forwarded. If there is more data available,the excessive data is kept in the buffer, because it must belong to the nextmessage. If there is less data, it is kept in the buffer as well, because it meansthe message has not yet fully arrived.

Future implementations should assure that data is read from all socketsin a round-robin fashion, so that small packets don’t have to wait for largepackets. Many design proposals still need to be implemented, as mentionedat the relevant places in this thesis.

34

4 Evaluation

One of the goals of this thesis is to show that anonymizing tunnels can bebuilt using normal broadband Internet connections and common desktop PChardware, thus eliminating the need for fast Internet connections and dedi-cated servers. This chapter will evaluate if Tap, which uses such tunnels, isable to deliver satisfactory performance to end users, which is a very impor-tant factor for the construction of anonymity networks [19].

4.1 Setup

The measurements were conducted to evaluate the influence Tap has on per-formance. To be able to compare results, Web site latency was measured:

• Non-anonymously, i. e., without using a proxy

• Anonymously, using Tap in the following constellations:

– Three fast relay nodes, located in the same local university net-work

– Three German ADSL nodes

– Two German ADSL nodes and one Brazilian cable modem node

• Anonymously, using Tor

The ADSL configuration was chosen to be close to a typical Tap user’s config-uration, using mainstream hardware and even shared Internet connections.However, no P2P file-sharing traffic was generated in order to be able tocompare the results of different series of measurements.

All page loads and measurements were performed on a client PC us-ing a mainstream ADSL connection from a major German provider, with10 Mbps downstream and 1 Mbps upstream. Interleaving [79] is activated bythe provider and accounts for a large fraction of the approx. 30 ms RTTbetween the home router and the first router on the provider network.

Another 2 ms are added by the delay between the client PC and the ADSLrouter, as they are connected via a wireless bridge. The router is also usedby three other persons for surfing on the Internet, emails, etc. This shouldbe a quite common scenario.

The PC performing the measurements is an Intel Centrino 1.8 GHz note-book with 512 MB of RAM. It runs on Canonical’s Ubuntu 8.04. During themeasurements, the machine was not used for any other activity.

35

4 EVALUATION

All three nodes that are used to construct the anonymous Tap tunnel areconnected to the Internet by ADSL connections. The upstream bandwidthof the nodes ranges from approx. 500 Kbps for the slowest node to approx.1100 Kbps for the fastest, downstream bandwidth ranges from 10 to 16 Mbps.One of the nodes provides Internet access to an office of approx. 70 computers,including several servers. In other words, the Internet connection is subjectto heavy use. The two other nodes are private ADSL Internet connectionsused by two persons each. In order to evaluate the influence of internationalconnections on Tap, another series of measurements was conducted with amainstream cable modem node located in Brazil.

Two types of measurements were conducted: Using Greasemonkey, ascript written in JavaScript was executed by the browser to measure realisticWeb site performance. Additionally, JMeter was used to measure latencyagainst file size. Greasemonkey and JMeter are explained in Section 4.1.3.

4.1.1 Testing Methodology

A Web browser was used to measure realistic results for the latency of Websites. In order to obtain a large number of samples, the Web browser wasscripted using Greasemonkey. The script used to perform the measurementis started by the browser and opens the first Web site of a fixed set. Whenthe Web site has loaded completely, the time is stopped and written to a logfile. Then, after a short delay the next Web site is opened and the processstarts over.

The reason for doing this directly from the browser and with JavaScriptis that it was the only method of safely determining when the browser hadfinished loading the Web site. Greasemonkey was used to inject the neededJavaScript to the Web sites. Section 4.1.3 has further details on how to useGreasemonkey.

The following Web sites were used for the analysis:

• www.google.de, as an example of a small and fast Web site with veryfew objects

• www.heise.de, which is a very popular and fast German IT news page

• www.spiegel.de, which is a very popular big news page

• www.web.de, which changes its content quickly

• edition.cnn.com, a foreign news page.

36

www.google.de

www.heise.de

www.spiegel.de

www.web.de

edition.cnn.com

4.1 Setup

4.1.2 Considerations

What matters to an end user is the amount of time needed for a requestedWeb page to show up. This waiting period begins when the URL of therequested page is entered and ends when the page is displayed. Displayingthe page does not necessarily mean that it is completely loaded. It may besufficient if only parts are displayed, but, for example, some of the graphicsare not yet displayed. However, this depends heavily on the Web site andthe user’s attitude. Therefore in this thesis the load time for a Web site isdefined as the time it takes to request, load, and display the complete page.

A typical request for a Web site begins with the resolution of the domainname. Upon reception of the resolved IP address, the browser tries to es-tablish a TCP connection to the Web server. As soon as the connection isestablished, a HTTP request for the main page of the Web site is sent. Thispage is then interpreted by the browser and all embedded objects such asimages, JavaScripts, etc. are requested from their respective servers, whichmay lead to new DNS requests and connection establishments. The followingwill detail how much time each step of the Web site retrieval requires andwhat attempts are made at reducing it.

DNS Lookups

To improve DNS lookups, Mozilla Firefox caches 20 DNS queries by default.However, if Web sites host their content on many different servers, the DNScache is too small to deliver previous DNS results.

Using recent MS Windows versions, DNS responses are cached locallyby the operating system. This prevents Web browsers from querying DNSservers for addresses that were requested recently. The time period theseresponses may be cached varies from a couple of minutes for some servers upto a couple of days for others.

Recent Ubuntu releases do not use a DNS caching mechanism by default.This means that every DNS request must be performed using the configuredDNS servers.

In the test setup, requesting DNS records from the hardware router tookbetween 3 and 50 ms, depending on whether the records were still cached inthe router or had to be requested from the ISP’s DNS servers. Load on therouter had a measurable influence on the DNS query time, as well. For low-latency Web sites, DNS requests considerably increase latency. To mitigatethe effects of DNS requests for the Ubuntu test machine, the DNS cachingsoftware dnsmasq was used, hence reducing the number of requests to thelocal router significantly.

37

4 EVALUATION

These considerations apply to the series of measurements conducted with-out proxy. By contrast, Tap and Tor do not resolve DNS addresses on theclient machine. This would compromise the anonymity, as an adversary maymonitor DNS requests and link requester to destination Web server. Instead,lookups are performed on the exit node and therefore depend on the exitnode’s operating system and Internet connection.

Connection Establishment

The time needed to establish a TCP connection from the client host to theWeb server is dominated by the network round-trip time (RTT). Packet tracesshow that for this setup the time needed to establish a connection to a Ger-man server is approx. 50 ms. This value is highly dependent upon the typeof Internet connection used. Many ADSL [74] connections currently in usein Germany make use of an error correction method named interleaving [79].In many cases, this can be disabled by the provider, but is often subject toadditional charges [2, 37].

Traceroute shows that the RTT to the first router in the provider network,the DSL Access Concentrator (DSL-AC) [73], is 30 ms. A large fraction of thisdelay is caused by the above mentioned interleaving between ADSL modemand DSL Access Multiplexer [77]. For example, the RTT to www.google.de

is approximately 50 ms. This means, that another 20 ms delay is introducedby intermediate routers and the Web server itself.

Server Response Times

The Web server has to receive and process the HTTP request and then sendthe response back, which will add a certain delay, depending on server loadand distance between client and server. Popular Web sites use content deliv-ery networks (CDN) [85] or operate a large number of fast redundant serversthemselves in order to keep this delay small. However, some ad servers [75]as well as other servers may be overloaded and hence discard requests. Thismay keep Firefox from completing a complex Web site retrieval, because ithas to wait for a single response. This behavior was observed several timesduring the measurements. A real user would either reload the page or ignorethe missing item, depending on its relevance. Therefore the measurementscript waits a maximum of 60 seconds for a Web site to complete loading. Ifthis timeout is exceeded, a load time of 60 seconds is logged for the currentsample and the measurement continues with the next page.

Geographical distance between Web server and client adds latency as well,which can be seen in the measurement series with the Brazilian Tap node in

38

www.google.de

4.1 Setup

Section 4.2.6.

Client Bandwidth

The bandwidth of the client’s Internet connection is important, as well. Ona regular ADSL connection, the downstream bandwidth is relatively highcompared to the upstream (e.g., 10 Mbps vs. 1 Mbps on the test setup).Normally the limited upstream bandwidth does not affect regular Web usage.However, anonymous Web surfing using Tap relies heavily on the upstream ofthe anonymizing nodes. Section 4.2 provides more details on how this affectsload times.

Browser Processing

Because modern complex Web sites like www.web.de use many JavaScriptsand Flash animations, browser processing may delay the user’s perception ofwhen a Web site has been completely loaded. This heavily depends on theprocessing speed of the client PC, type and version of the browser as well asthe operating system. In order to mitigate these effects for the measurement,Flash animations will not be displayed, however, they will still be loaded fromthe server and will therefore produce a similar network load. The Firefoxplugin Flashblock [10] is being used to block Flash animations.

Browser Optimization

Modern browsers use several cache [27] mechanisms to speed up the retrievalof Web sites. Firefox uses a disk cache, which has a capacity of 50 MB bydefault. Firefox also uses a memory cache, which delivers recently fetchedobjects much more quickly than the disk cache. Its size is proportional tothe system’s memory. If an image is displayed more than once on the sameWeb page, it will be downloaded only once and will then be reused. If thememory cache is disabled, Firefox will download this same image as manytimes as it is displayed on that page. This leads to substantial performancesacrifices on certain Web sites, especially if used with Tap or Tor.

Depending on the surfing habits of the user, more or less page contentmay be fetched from the local cache. Therefore two series of measurementswere conducted. The first one applies to the initial loading of a Web site, i. e.,without using the local cache. An example would be a user accessing a Website not accessed recently. The second series of measurements was conductedin order to evaluate subsequent loading of a Web site. This corresponds toa user who is repeatedly using the same Web site, as is the case for Internetsearch engines, news sites, Web mail, etc.

39

www.web.de

4 EVALUATION

To simulate initial loading of a Web site, the disk cache in Firefox is dis-abled during the measurements. The size of the memory cache is reduced to2 KB, which is too small to cache Web site elements between page loads, butavoids having to load one and the same image on a single Web page multipletimes. For subsequent loading of a Web site, Firefox’ default configuration isrestored, i. e., all caches are enabled during the measurement.

Another feature Firefox uses are HTTP Keep-Alive connections, as ex-plained in Section 2.5. This enables Firefox to reuse TCP connections thatwere set up earlier and therefore save the time that would have been neededto establish the TCP connection to the Web server. Firefox also supportsHTTP pipelining, although it is disabled by default, probably due to incom-patibilities with certain Web servers [78]. The corresponding configurationvalues may be looked up in [27].

4.1.3 Performance Evaluation Tools

Different tools were evaluated in order to analyze Tap’s performance char-acteristics. The goal was to find a tool that can automate the process ofmeasuring realistic load times for complex Web sites.

Firebug Firebug [35] is a browser plugin for Web developers. Its networkmodule measures and graphically displays the time needed to retrieve eachobject of a Web site as shown in Figure 9. The time displayed for eachobject is the time needed to receive the HTTP header, not the entire ob-ject. Evaluating packet traces delivers very similar results, which leads tothe conclusion that Firebug works very precisely. Firebug also reveals thechronological order in which objects are requested as well as the correspond-ing headers, which can be helpful for debugging. As Firebug passively mon-itors the browser behavior, any performance enhancements that the browseruses, such as keep-alive connections and parallel retrieval of Web site objectsare taken into account.

Firebug is an excellent choice to get an overview of performance but itlacks support for scripting and data export.

GNU Wget Wget [13] is the default command line tool in many Linuxdistributions for downloading online content. It has built in proxy supportand a basic Web site parser. Using the appropriate options, it can downloadan entire Web site for offline viewing. However, it does not seem to interpretactive content as JavaScript, etc. Wget would have been a perfect choicefor scripting and measuring, but it is not able to retrieve embedded objectssimultaneously. This results in significant performance loss when used with

40

4.2 Results

Tap, as explained later. Therefore Wget is useless if realistic performancemeasurement from a user point of view is required.

There exist a couple of modified Wget variants, but none of them offers allthe required properties such as proxy support, persistent connections, Website parsing, and simultaneous retrieval of embedded objects.

Greasemonkey Greasemonkey [45] is a browser plugin, that helps userscustomize the way a Web site is displayed in their browser. This is achievedby using JavaScript, which is locally applied to the Web pages. Greasemon-key manages a list of user supplied JavaScript files and applies them to thespecified Web sites. There is a big collection [11] of free JavaScript files thatcan be used with Greasemonkey.

Greasemonkey will be used to evaluate the performance of Web pages.Measuring performance for proxies like Tap and Tor poses no burden, becausethe proxy settings for Firefox apply to Greasemonkey as well. A script waswritten that repeatedly loads a set of Web pages, measures the total loadtime for every page, and then displays the results on a separate Web page,from where they may be copied and evaluated. This approach has the greatadvantage of measuring realistic load times from a user point of view.

Apache JMeter JMeter [54] is a free load generation and measurementtool, written in Java. It was designed to measure the performance of Webapplications and therefore allows the definition of detailed test plans. JMeterwill be used to analyze how Tap is influenced by the size of Web page objects.

JMeter has an option to automatically parse retrieved Web pages anddownload all embedded objects, which would theoretically eliminate the needfor the Greasemonkey script. Unfortunately, this feature is useless in thecontext of this thesis, because it downloads every object sequentially andtherefore does not take advantage of parallel requests like a real browser.

4.2 Results

This section presents the results of the measurements. The following para-graphs will provide a general performance comparison, show the differencesbetween initial and subsequent Web site access, evaluate the influence ofother traffic on the nodes, and will also analyze the components the loadtime is composed of.

41

4 EVALUATION

load

dur

atio

n in

ms

5000

10000

15000

20000

25000

CNN Google Heise Spiegel Web.de

(a) TOR


(b) TAP (ADSL/Germany)

(c) No Proxy

5000

10000

15000

20000

25000

(d) TAP (University Network)

Figure 5: Comparison of cached Web site downloads using no proxy, Tap overfast university network, Tap over ADSL nodes, and Tor

Mean Median σ Samples

No Proxy 209 200 37 63Tap (University) 206 195 29 37Tap (ADSL) 606 484 476 65Tap (Germany/Brazil) 1480 1415 702 150Tor 5217 4462 2250 39

Table 3: Summary of load times in ms for www.google.de, cache enabled

No. of Objects Total Size in KBComplete Cached Complete Cached

Google 3 1 18 3Heise 45 15 165 7Spiegel 125 15 910 25/200Web.de 125 20 280 50CNN 110 10 650 50

Table 4: Comparison of Web page objects for complete and partial loads

42

www.google.de

4.2 Results

12:51:54 13:27:27 14:12:27 14:58:57 15:40:42 16:20:09 16:57:51 17:39:03 18:11:57

020

0040

0060

0080

0010

000

time

load

dur

atio

n in

ms

(a) Load duration measured over a period of five hours

500 550 600 650 700

010

0020

0030

00

sample

load

dur

atio

n in

ms

(b) Tor traffic artifact

Figure 6: Google load time using Tor (cache enabled)

43

4 EVALUATION

4.2.1 General Comparison

Figure 5 depicts the load time of the Web sites listed in Section 4.1.1, for fourdifferent access configurations, i. e., without using a proxy (c), anonymousaccess over Tor (a), anonymous access using Tap with tunnel nodes locatedin the university (d), and anonymous access using Tap with ADSL tunnelnodes in Germany (b). Table 3 shows the number of samples taken for eachWeb site; measurements were conducted at least one hour for every accessconfiguration. No operating system DNS cache was used during these seriesof measurements, but all browser caches were left at their default values,i. e., enabled. In a boxplot [84], the vertical extension of a box represents theinterquartile range (IQR) and thus 50 percent of the samples are representedby the box. The dot or line in the middle indicates the median. Samples thatare within 1.5 times the IQR are represented by the dotted lines; all othersamples are considered outliers and are drawn separately as circles.

Table 3 reveals that the results for Google are slightly better for theconfiguration with Tap and university nodes than for directly accessing theInternet without a proxy. This sounds paradox, but there is a simple ex-planation for this that involves the faster connection establishment from theuniversity nodes compared to the test machine. Before the request can besent to the Web server, a connection has to be established which takes ap-prox. 50 ms on the test machine. After the connection is established, therequest can be sent and the entire response is received approx. 80 ms later,which makes a total of approx. 130 ms. If Tap is used and the anonymoustunnel is already established, the request can be sent immediately throughthe tunnel to the exit node, which takes approx. 30 ms, because the tunnelnodes are connected through a LAN. Then the connection to the Web serverhas to be established, which only takes about 20 ms. After successful con-nection establishment, the request is sent and the entire response is receivedwithin approx. 40 ms. Another approx. 30 ms are needed to forward the re-quest back to the initiator, which makes a total of approx. 120 ms and istherefore slightly faster than the direct access.

The boxplots in Figure 5 give an impression of Tor’s speed compared toTap and non-anonymous access; Table 3 shows that loading www.google.de

via Tor is in average 25 times slower than without Tor. The two most likelyreasons for this are high latency in tunnel paths due to (intentional) geo-graphical distance, and congestion on the server nodes. Figure 6 (a) shows adifferent series of measurements with approximately 4000 samples of repeatedreloading of www.google.de for a period of five hours. It clearly shows thatthroughout the measurement the tunnel was rebuilt multiple times using dif-ferent servers with different speeds. From 14:19 - 14:32, 16:22 - 16:32, 18:04

44

www.google.de

www.google.de

4.2 Results

- 18:19 the tunnel - called a virtual circuit in Tor - delivered the Web sitecontents very quickly and with low variance. The default time in which a Torcircuit may be reused is “10 minutes or so”[56, 12], which correlates to theabove mentioned time slots. The rest of the time, load times may be largeand show a very high variance.

Another interesting thing to be observed are the traffic artifacts in Fig-ure 6 (a), which look like slightly tilted vertical stripes. Figure 6 (b) shows anextract thereof, displaying approximately 200 samples. The reason for this isnot yet fully clear. Murdoch et al. describe similar patterns in [52] and givepossible explanations. According to them, the artifacts could be due to in-teractions between the different streams transported over the same OR. Toruses a non-blocking polling strategy [52] to check if data is available on a perstream basis. Every stream is checked for data using a round-robin schedule;if data is available, it is forwarded, otherwise the next stream is checked im-mediately. This guarantees fair processing for each stream. Murdoch et al.argue that this may leak information about the number of streams currentlyserved by an OR. This scheduling might be the cause for the artifacts inFigure 6 (b), as well. Further investigation is needed to verify this.

The varying server load, due to varying numbers of relayed streams, aswell as the changing ORs, explain the high variance of the load times, whichis shown by the large expansion of the boxes in Figure 5. This applies toall five measured Web sites. The fact that cnn.com is the second fastestWeb site and much faster than spiegel.de and web.de is probably becauseCNN [57] uses a Content Delivery Network (CDN) [85], that delivers dataquickly no matter from where in the world it is requested. Spiegel.de andweb.de, however, are hosted on German servers and do not seem to make useof CDNs. Therefore connections to their servers are subject to higher latency,if accessed from distant locations. Since roughly three quarters of Tor’s exitnodes are located outside of Germany [43], Tor requests to the German Webservers are likely to suffer from higher latency.

Tap does not suffer such large load times neither do the load times varythat much. However, an additional series of measurements presented in Sec-tion 4.2.6 shows that using international nodes for Tap tunnels adds signifi-cant delay to the load time.

4.2.2 Load Duration of Initial Web Site Access

When a user has not accessed a Web site for a while, the browser will probablyneed to load its entire content, because the content will no longer be availablefrom the local cache. The boxplots [84] in Figure 7 show how the load timechanges when the Web site is accessed anonymously through a tunnel of three

45

cnn.com

spiegel.de

web.de

Spiegel.de

web.de

4 EVALUATION

●●●

●

●

●

●●●●●●●●●●●●●●●

●●

●

●●●

●

●

●

●

●●

●

●

●


050

0010

000

1500

0

load

dur

atio

n in

ms

(a) Direct connection (no proxy)

●●●●●●

●

●

●

●

●●


050

0010

000

1500

0

load

dur

atio

n in

ms

(b) TAP over ADSL

Figure 7: Time needed to initially load Web sites (cache disabled)

Tap nodes as compared to a non-anonymous access. Figure 7(a) is based on76 samples for each Web site; Figure 7(b) is based on 50 samples.

Table 4 compares complete and partial page loads. Complete refers topage loads where none of the embedded objects could be found in the localbrowser cache; partial refers to page loads, where some of the objects did nothave to be loaded from the Internet because they could be taken from thebrowser cache. The presented values are averages based on a few samples.For www.spiegel.de the index.html file was served by the local cache exactlyevery second load, therefore two values are given for the size. Figure 7 showsthat the load time of www.spiegel.de increases more than that of the othersites if loaded over Tap on ADSL nodes. A possible explanation for this is thebigger size compared to the sizes of the other Web sites. Due to the limitedupstream capacity of the ADSL tunnel nodes, the physical transmission ofdata and overhead already requires more than eight seconds.

The data shows that the median of the load times for Tap is approximately3.5 to 6 times higher than without Tap, depending on the Web site. Aninteresting result is that the variance is not affected significantly, which isshown by the small vertical extension of the boxes. Except for this series ofmeasurements, all other measurements were conducted with browser cachesenabled.

46

www.spiegel.de

www.spiegel.de

4.2 Results

●

●

●

●●●●●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●●


010

0020

0030

0040

0050

0060

00

load

dur

atio

n in

ms

(a) Direct Connection (no proxy)

●

●

●

●

●●●●●●●

●●

●●●●●●●●

●

●

●

●

●

●●●

●

●


010

0020

0030

0040

0050

0060

00

load

dur

atio

n in

ms

(b) TAP over ADSL

Figure 8: Time needed to subsequently load Web sites (cache enabled)

(a) Complete load

(b) Cached load

Figure 9: Comparison of disabled vs. enabled cache

47

4 EVALUATION

4.2.3 Load Duration of Subsequent Web Site Access

By contrast, if a user has opened a Web page and then uses a link to navigateon the same site, the browser will not have to reload all objects of that site.Also, the user may reuse a certain Web page multiple times. Google’s mainpage [81] consists of more or less three objects: the main HTML page andtwo images. If the page is reloaded, only the HTML part is requested overthe Internet; the images are loaded from the local cache. According to theHTTP response header, the images may be reused from the local browsercache for the next 30 years. This makes the process of loading a Web pagemuch faster compared to loading the complete Web page over the Internet.Figure 9 shows the different objects that are fetched and the correspondingload times; the cache was not used in (a), whereas in (b) it was used.

Figure 8 shows the load times for non-anonymous Internet access in com-parison to anonymous Internet access via Tap, using the local browser cache.The results are very similar to those in Figure 5, but more samples weretaken and only the relevant details are shown. Figure 8 (a) is based on 112samples per Web site, Figure 8 (b) is based on 173 samples.

The results show that using Tap over three German ADSL nodes increasesthe load time of the measured Web sites by the factor two to three, comparedto non-anonymous Internet access. The higher variance of Spiegel comparedto those of the other pages is probably due to the index.html being loadedfor every second sample, as described above. The size of this file is approx.180 KB, which needs more than 1.5 seconds just for transmission over thelimited 1 Mbps upstream. If the times measured for half of the samplesinclude this file and the other half does not, it is clear that the variance willrise.

4.2.4 Influence of Congested Nodes on Tap Performance

Another important aspect was to analyze how Tap’s performance is influ-enced by other network traffic on the tunnel nodes, that is, traffic generatedby other applications on the tunnel node that is not linked to Tap. Figure 10shows how Tap performs for varying traffic types on the exit node. The mainpage of www.google.de is reloaded every three seconds, provided that theprevious page load had already terminated; browser caches were enabled.

The left section of the plot shows the load times during a period of verylow load on the tunnel nodes. Then, heavy upstream traffic was generatedon the exit node by transmitting a video over a terminal server connection,which saturated the upstream link capacity of approximately 1 Mbps. Theright section shows a period of heavy downstream activity on the exit node,

48

www.google.de

4.2 Results

●

●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●

●

●

●

●●●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●●

●

●

●●●●●●●●●●●●●●●●●●●●

●●●●●●●

●

●●●●●●●●●●●●●●●●●

●

●●●●●●●●

●

●●●●

●

●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●

●●●●●●●●●●●●●

0 100 200 300 400

1000

2000

3000

4000

sample

load

dur

atio

n in

ms

No load

Upstream load

Downstream load

Figure 10: Influence of congested tunnel nodes on load times for www.google.de

which was generated by downloading a large file from a fast Web server.

It can be seen that a congested low bandwidth uplink has a significantinfluence on Tap’s performance. However, conventional Web applicationsthat run over a consumer Internet connection usually do not make heavy useof the upstream. There is at least one exception to this rule: peer-to-peer file-sharing traffic. Since Tap is meant to be bundled with file-sharing software,measures should be taken to prioritize Tap traffic over regular file-sharingtraffic within the application logic. Although the load time and variance dorise significantly, it must also be noted that almost all page loads finish withintwo seconds, so that Internet access still seems feasible.

Finally, the right section shows the influence downstream traffic has onTap’s performance. With the exception of a few outliers, performance isvirtually not affected by downstream traffic on an exit node. This makessense, considering that the bottleneck is the slowest upstream connection inthe tunnel, which is between 500 Kbps - 1 Mbps, and not the downstream,which is 16 Mbps in the test scenario.

Since this series of measurements was conducted only for Google, futuremeasurements with different Web sites will have to show if these results canbe generalized.

49

www.google.de

4 EVALUATION

●

●

●●●●●●

●

●

●

No Proxy Tap (University) No Proxy Tap (University)

050

010

0015

00

load

dur

atio

n in

ms

Google

Heise

Figure 11: Influence of Tap overhead, measured with 3 high bandwidth, low-latency university nodes, for www.google.de and www.heise.de

4.2.5 Overhead Induced by Tap

Figure 11 compares load time and variance for Web page access with andwithout Tap. Google’s and Heise’s main Web page serve as examples.

The boxplot shows that the distribution of the load duration is nearlyidentical for the two cases. In other words, it makes no difference to an enduser if a Tap tunnel with high-bandwidth, low-latency nodes is used, or if thepage is downloaded directly without a proxy. These results suggest that theTap software itself induces only very little overhead, and that performancelosses are mostly due to latency and bandwidth properties of the participatingnodes as well as their current congestion.

4.2.6 Influence of Node Speed and Location on Tap Performance

To examine the influence an overseas link in the Tap tunnel has, a node inBrazil was used in one series of measurements. Figure 12 shows three seriesof measurements. The left section of the plot shows load durations using atunnel consisting of high bandwidth, low-latency nodes; the middle sectioncorresponds to a tunnel using ADSL nodes of a major German provider; andfinally the right section shows values for a tunnel consisting of two GermanADSL nodes and one cable modem node located in Sao Paulo, Brazil. Thevalues are the load duration in ms for the main page of www.google.de.Browser caches were enabled all the time.

50

www.google.de

www.heise.de

www.google.de

4.2 Results

0 50 100 150 200 250 300 350

010

0020

0030

0040

00

sample

load

dur

atio

n in

ms

University ADSL Germany

ADSL Germany/Brazil

Figure 12: Influence of location and latency of Tap nodes on load times, measuredwith www.google.de and cache enabled

load duration in ms

Fre

quen

cy

800 1000 1200 1400 1600 1800 2000

010

2030

40

Figure 13: Histogram of load duration for www.google.de using Tap tunnel overBrazil

51

www.google.de

www.google.de

4 EVALUATION

The plot shows that adding a cable modem node in Brazil results inapproximately tripling the load time for www.google.de as compared to usingonly German ADSL nodes. The main reason for this is the large round-trip time from Germany to Brazil in the tunnel, which accounts for nearly300 ms. The connection time from the exit node, in this case in Brazil,to the destination Web server depends on the Web server location and ifthe site uses CDNs. For www.google.de this was approximately 180 ms,whereas www.heise.de needed 270 ms. The request for Google was answeredin the US, whereas the request for Heise had to travel all the way back toGermany. Depending on the ISP, CDNs might be able to deliver contentrapidly independent of the client location. There is a Web site [42], thatlists international Web sites that can be used to traceroute Web servers fromdistant locations.

Although the load time is approximately tripled, the variance of the loadtimes observed is low. Roughly 75 percent of the values are between 1250 and1550 ms, as illustrated by Figure 13. In the following section the componentsof the load time are described in detail.

4.2.7 Analysis of Load Time

Figure 14: Tap tunnel using ADSL anduniversity nodes, with sample delays

The following paragraph will explainwhy loading Web pages over Tapis slower than directly accessing theWeb pages without Tap. Figure 14illustrates the nodes that participateto anonymously fetch a Web page.The delays introduced by each linkare given for a sample page load ofwww.google.de; by link the connec-tion between two Tap nodes used forrelaying is meant. The tunnel con-sists of an entry node with an ADSLconnection and an intermediary andan exit node on a high bandwidth,low-latency university network. The

RTT on the link between Tap client and entry node is approx. 80 ms.Main reasons for this delay are interleaving between modem and DSLAM,TCP/IP [66], PPPoE [47], LANE [63, 66], and ATM [66] overhead, as well asthe limited upstream bandwidth of both nodes. The reasons for the delayof 60 ms introduced by the link between entry node and intermediary nodeare the same as for the above connection, with one exception: The upstream

52

www.google.de

www.google.de

www.heise.de

www.google.de

4.2 Results

of the intermediary node is not limited like the ADSL upload and thereforedoes not introduce significant delays. The delay introduced by the connectionbetween intermediary node and exit node is negligible, because they are con-nected by a fast local area network (LAN). Before the exit node can relay theHTTP request, a connection to the Web server has to be established. Thistakes approx. 20 ms. Then, another 40 ms are needed to transmit, process,and answer the request.

The total time needed to load the Web page is the sum of the delaysintroduced by each link and adds up to approx. 200 ms.

4.2.8 Tunnel Establishment

The additional time needed to establish an anonymous tunnel with Tap wasestimated by evaluating five samples for tunnels over ADSL nodes. Theseresults apply only to the special case where all three nodes for the tunnelare reachable. Approximately 350 ms elapse from starting the tunnel estab-lishment until receiving a confirmation message from the exit node. Approx.200 ms later the first response packet from the Web server is received by theclient PC. The tunnel setup time mainly comes from the TCP connection-establishment between the tunnel nodes as well as subsequent forwardingof the tunnel establishment packet. At the same time the tunnel establish-ment confirmation packet is traveling back through the tunnel, the HTTPrequest is already forwarded from the exit node to the Web server (comparewith Table 1 for the tunnel establishment packet). This significantly reducesthe time that is wasted for tunnel establishment. Compared to Web siteloads through already established tunnels, the tunnel setup adds a constantoverhead of roughly 250 ms. Again, this result only applies to the specificconfiguration of three reachable ADSL nodes. If during the tunnel setupone of the tunnel nodes is not available, the tunnel setup time is increasedsignificantly, as explained in Section 3.2.3.

4.2.9 Influence of Object Size on Load Time

Figure 15 shows the load time for objects of different sizes, measured withJMeter using Tap with three ADSL nodes. Both the x-axis and the y-axis arescaled logarithmically. It shows that for file sizes between 1 and 10 KB, loadtime mostly depends on the RTT, whereas for objects bigger than 10 KB, thetransmission time becomes the dominant factor responsible for latency.

53

4 EVALUATION

●

● ● ●●

● ●● ●●●

●●

●●

●

●

●● ●

● ● ● ●●●

●●

●

●

●

● ● ● ● ● ●●

●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●●

●●

●

● ● ● ● ● ● ● ●

●●

●

●●

●

●

● ● ● ● ● ● ●●●●

●

●●

●

●

● ●● ● ● ● ● ●

●●

●

●●

●

●

● ● ● ● ●● ● ●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●

●●

●

●

●● ● ● ● ●

● ●●●

●●

●●

●

● ● ● ● ● ● ●●●●

●● ●

●

●● ● ● ● ● ● ● ●

●●

●●

● ●

●● ● ● ● ● ● ● ●

●●

●●

●

●

●●

● ● ● ● ● ●●●●

●

● ●

●

●

● ●● ● ● ● ● ●

●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●

●

● ●

●● ● ● ● ● ● ● ●

●●●

●●

●

●● ● ● ● ● ● ● ●

●●

●

●●

●

●● ● ● ● ● ● ● ●

●●

●●

●●

●

●

● ● ● ● ● ● ●●●

●

●●

●

●

● ●●

● ●

●

● ●●●

●●

●

●

●●

● ● ● ● ● ●

●●

●

●● ●

●

●●

● ● ● ● ● ● ●●●

●

● ●

●

●●

● ● ● ● ● ● ●●●

●

●●

●

●

● ● ● ● ● ● ●●

●● ●

●

● ●

●

● ● ● ● ● ● ● ●●●

●●

●

●

●

●● ● ● ● ● ● ●●●

●

● ●●

●

● ● ● ● ● ● ● ●●●

●●

●●

●

●● ● ● ● ● ● ●

●●●

●

●

●

●●

●●

● ● ● ● ●●●

●●

●●

●

●● ● ● ● ● ● ●●

●●

●●

●

●

●●

● ● ● ● ● ●

●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ●● ● ●

●●

●●

●

●

●●

● ● ● ● ● ● ●●●

●

●

●●

●●

● ● ●●

●● ●●●

●

●●

●

●

● ● ● ● ● ● ●●

●●

●

●●

●

●● ● ● ● ● ●

●●

●●

●

●● ●

●●

● ● ● ● ● ● ●●●

● ●●

●

●

●● ● ● ● ● ● ●

●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●● ● ● ● ● ● ● ●

●●●

●

●●

●

●● ● ● ● ●

●●●

●●

●●

●

●● ● ● ●

●● ● ●

●●

●●

●●

●●

● ● ● ● ● ● ●●●

●●

●

●

●●

● ● ● ●● ● ●●

●

●●

●●

●● ● ● ● ● ●

●●

●●

● ●●

●

●

●● ● ● ●

● ● ●●●

●●

●

●

●

●

●

● ● ● ●● ●

●●

●

●●

●

●●

● ● ● ●● ● ●

●●

●● ●

●

●●

● ● ● ● ● ● ●

●●

●

●

●●

●●

● ● ● ● ● ● ●●

●

●●

●●

●

● ● ● ● ● ● ● ●●●

●

● ●●

●

●● ● ● ●

● ● ●●●

●●

●

●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●

● ●

●

●

●● ●

● ● ● ● ●●●

●

●

●

●

●●

● ● ● ● ● ● ●●●

●

● ●●

●

● ● ● ● ● ● ● ●●●

●●

●●

●●

●●

● ● ● ● ●●●

●●

●●

●●

● ● ● ● ● ● ●

●●

●●

●●

●

●● ● ● ● ● ● ●

●●

●

●

● ●

●●

● ● ● ● ● ● ●●●

●●

●

●

●● ● ● ● ● ● ● ●

●●●

●● ●

●

●● ● ● ● ●

●●●

●

●●

●●

●●

● ● ● ● ● ●●

●●●

●

● ●

●

● ● ● ● ● ● ● ●

●●●

●

●●

●

● ● ● ● ● ●

●●

●●

●

●●

●

●● ● ● ● ● ● ● ●●

●●

●

●●

●●

● ● ● ● ● ● ●●●

●

●●

●

●● ● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ● ● ●●

●●

●●

●

●

●●

● ● ● ● ● ● ●●

● ●● ●

●

●

●● ● ● ● ● ● ●●●

●●

●

●

●

● ● ● ● ● ● ●●

●●●

●

● ●

●●

● ● ● ● ● ● ●

●●

●

●

● ●

●● ● ● ● ● ● ● ●

●●●

●●

●

●

● ● ● ● ● ● ●●●●

●●

●●

●●

● ● ● ● ● ●●

●●

●●

●

●

●● ● ● ● ●

● ● ●●●

●

●

● ●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●●

● ●

●● ● ● ● ● ● ●

●●●

●

●

●●

●

●● ● ● ● ●

● ●●●

●

●●

●

●● ●

●

● ● ● ● ●●●

●

●

●

●

●● ● ● ● ● ● ● ●●

●

●

●●

●

●

● ● ● ● ● ● ●●●●

●

●●

●

●

● ● ● ● ● ● ●●

●●●

●

● ●

●●

● ● ● ● ● ● ●

●●

●

●

● ●

●●

● ●● ● ● ● ●●

●●

● ●

●

●

● ● ● ● ●

● ● ●●

●

●●

●

●

●●

● ● ● ● ● ● ●●●

●●

●●

●●

● ● ● ●● ● ●

●●

●●

●●

●●

●● ● ● ● ● ●●

●

●

● ●●

●●

● ● ● ● ● ● ●●●

●●

●

●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●

●● ● ● ● ●

● ●

●●

●●

●●

●●

● ● ●●

● ● ●

●●

●

●

●●

●●

● ● ● ● ● ●●

●●

● ●

● ●

●● ● ● ● ● ●

●●●●

●●

● ●

●●

●● ● ● ● ● ●●

●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●●

●●

●● ● ● ● ● ● ● ●●

●

●●

●●

●●

● ● ● ● ● ● ●●●

●

● ●●

●● ● ● ● ● ● ● ●●

●

●

●●

●

●● ● ● ● ● ● ● ●●

●●

●

●●

●

● ● ● ● ●● ● ●

●●

●

●●

●

●●

● ● ● ● ● ●●●●

●●

● ●

●● ● ● ● ● ● ●

●●

●●

●●

●

●

●● ● ● ● ● ● ●

●●

●●

●●

●

● ●● ● ● ● ● ●●

●●

●●

●

●

●● ● ● ● ● ●

●●●

●●

●●

●●

● ● ● ● ● ● ●●●

●

●●

●

●● ● ● ● ●

●● ●●●

●●

●

●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●●

●● ● ● ● ● ●

●●

●●

●●

●

●●

● ● ● ● ● ●●

●●

●●

●

●● ● ● ● ● ●

● ●●●

●

●

● ●

●● ● ● ● ● ● ● ●●

●●

●●

●

●●

● ● ● ● ● ● ●●●

● ●●

●

●

●● ● ● ● ● ● ●●

●●

●

●●

●●

● ● ● ● ● ● ●●●

●

●

●●

●●

● ● ● ● ● ● ●●

●●

●●

●

●

● ●● ● ● ● ●

●●

●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●

●

● ●

●●

● ● ● ● ● ● ●●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●

● ●

●

●●

● ● ● ● ● ●●●●

●

●

● ●

●● ● ● ● ●

●●

●●

●

●●

●●

●● ● ● ● ● ● ● ●●

●

●

●●

●

●● ● ● ● ● ● ● ●

●●

●●

●

●

●●

● ● ● ● ● ●●

●●

●

●●

●

●

● ● ● ● ● ● ●●

●●

●● ●

●

●● ● ● ● ● ● ● ●●

●

●●

●

●

●●

● ● ● ● ● ● ●●●

●

● ●

●

●●

● ● ● ● ● ● ●

●●

●●

●●

●●

● ● ● ● ● ● ●

●●

●

● ●

●

●

● ● ● ● ● ● ● ●●●

●●

●

●

●

● ● ● ● ● ● ● ●●

●●

●●

●

●

● ● ● ● ●● ● ●

●●

●●

●●

●●

●● ● ● ● ● ●●

●

●●

●

●

●

●

● ● ● ● ●●

●●

●●

●●

●

●

●● ● ● ● ● ● ●

●●●

●●

●

●●

●● ● ● ● ● ●●

●

●

●

● ●

●●

● ● ● ● ● ● ●●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●●

●●

●

●● ● ● ● ● ●

●●●

●

●●

●

●●

●●

● ● ● ● ●●●

●●

●●

●●

● ● ● ●● ●

●●●

●●

●

●

●

●● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ●

●● ●●

●

●

● ●●

●● ● ● ● ● ● ● ●

●●

● ●

●

●

●● ● ●

●

● ●●

●●●

●

●●

●

●● ● ● ● ● ● ● ●●

●●

●●

●

●● ● ● ● ● ● ● ●●

●●

●

●●

●●

● ● ●● ● ● ●●

●●

●●

●

●●

● ● ● ●● ●

●

●

●

●●

●●

●●

● ● ● ● ● ● ●●●

●●

●●

●●

● ● ● ● ●

●

●●●

●

●

● ●

●

●

●● ● ● ● ● ●

●●

●●

● ●

●●

● ● ● ● ● ● ●

●●

●

● ●●

●

● ●● ● ● ● ● ●

●●

●

● ●

●

●●

● ● ● ● ● ● ●

●

●

●

●

●

●

●● ● ● ● ● ● ●

●●●

●

●●

●

●

●

●● ● ● ● ●

●●

●●

● ●●

●

● ● ● ● ●●

● ●●●

●●

● ●

●

● ● ● ● ● ● ● ●

●

●

●

●● ●

●●

● ● ● ● ● ●●●●

●●

●

●

●

● ●● ● ● ● ● ●

●●

●

● ●

●

●

● ●● ● ● ● ● ●●

●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●●

●

●

●

● ● ● ● ● ● ●●

●●

●●

●

●

●●

● ● ● ● ● ● ●

●●

●

●

●●

●●

● ● ● ● ● ● ●●●

●●

●●

●

● ● ● ● ●● ● ●●●

●

●●

●

●● ●

● ● ● ● ● ●

●●

●

●●

●

●

●● ● ● ●

● ● ●●●

●●

●

●

●● ● ● ● ● ● ● ●

●●

●

●●

●

●

●

●

●

●

●●

● ●●●●

●●

●

●●

● ● ● ● ● ● ●●●

●●

●

●

●

● ● ● ● ● ● ● ●●

●●

●●

●

●●

● ● ● ● ● ●●●

●

●●

● ●

●

● ● ● ● ● ● ● ●●●

●

● ●●

●

●

●● ● ● ● ● ●●

●●

●

● ●

●● ● ● ● ● ● ● ●

●●

●

● ●●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●

●

●●

●

● ● ● ● ●● ● ●

●●

●●

●

●

●●

● ● ● ● ● ● ●●●

●●

●

●

●●

● ● ● ● ● ● ●●●

●

●

●●

●● ● ● ● ● ● ●

●●●●

● ●●

●● ● ● ● ● ● ● ●

●●

●●

●●

●

● ● ● ● ● ● ● ●●●

● ●●

●

●● ● ● ● ●

●● ●

●●

●●

● ●

●

●● ● ● ● ● ●

●●●

●●

●●

●●

● ● ● ●● ● ●●

●

●●

●●

●● ● ● ● ● ● ●

●●●

●●

●●

●

● ● ● ● ● ● ●●●

●

●● ●

●

●● ● ● ● ● ● ● ●

●●

●

●● ●

●● ● ● ● ● ● ● ●●

●●

●●

●

●● ● ● ● ● ● ● ●●

●●

●

●●

●● ● ● ● ● ●

●●

●●

●●

●

●

●●

● ● ● ● ● ● ●●●

●

●●

●

●● ● ● ● ●

● ●●●●

●●

●

●

●

● ● ● ● ● ● ● ●●

●

●●

●

●

●● ● ● ● ● ● ● ●●

●

●●

●●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●● ●

● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●●

●●

●● ● ● ● ● ●

●●

●●

●●

● ●

●●

● ● ● ● ● ● ●●●

●

●●

●

●

●● ● ● ● ● ● ●●

●

●●

●

●

●●

● ● ●

●●

● ●●●

●●

●

●

●●

● ● ● ● ● ● ●●●

●

●

●●

●

●● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ● ● ● ●

●●●

●●

●

●● ● ● ● ●

●● ●

●●

●

●●

●

●●

●

● ● ● ●●

●●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●●

●

●

●●

●●

● ● ● ● ●

●●

●●

●●

●

● ● ● ● ●●

● ●●●

●

● ●

●

●●

●● ● ● ● ● ●●●

●●

● ●

●

● ● ● ● ●●

● ●

●●

●●

●

●

●●

●● ● ●

●● ●●●

●

●● ●

●● ● ● ● ●

● ● ●●●

●

●● ●

●●

● ● ● ● ●●

●●●

●●

● ●

●

● ● ● ● ● ● ● ●●●

●

● ●

●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●

●●

●

●● ● ● ● ● ● ● ●

●●

●●

●●

●●

● ● ● ●● ● ●

●●

● ●

●●

●

● ●●

● ● ● ●●●

●

●●

●●

●● ● ● ● ● ● ●

●●● ●

●

●●

●

● ● ● ● ● ● ●●●●

●

● ●

●

●● ● ● ● ● ● ● ●

●●

●●

●●

●●

●● ● ● ● ● ●

●●

●●

●

●

●

●

● ● ● ● ● ●●

●● ●

●

●●

●

●● ● ● ● ● ● ●●

●

●

●●

●

●● ●

● ● ● ● ● ●●●

●●

●●

●

● ● ● ● ● ● ● ●●●

●

●●

●

●

●● ● ● ● ● ●

●●●

●●

● ●

●

● ● ● ● ● ● ●●●●

●

●●

●

●

● ● ● ● ● ● ● ●●●

●

●

●●

●●

● ● ● ● ● ● ●●●

●

●●

●

●● ●

●

● ● ●●

●●

●●

●●

●

●●

● ● ● ● ● ● ●●●

●

●● ●

●● ● ● ● ● ● ● ●

●●

●●

●●

●

● ● ● ● ● ● ● ●

●●

●●

●●

●●

● ● ● ● ● ● ●

●●

●●

●●

●

● ●● ● ● ● ●

●●●

●●

●●

●

● ● ● ● ● ● ● ●●●

● ●

●●

●● ● ● ● ● ● ●

●●●

●

●● ●

●● ● ● ● ● ● ● ●●●

●

●

● ●

●●

● ● ● ● ● ● ●●●

●●

●●

●

● ● ● ● ●● ● ●

●

● ●

●●

●●

●●

● ● ● ● ●●●●

●

●●

●

●●

● ● ● ● ● ● ●●●

●

●

● ●

●● ● ● ● ● ● ● ●

●●

●●

●●

●

●

●● ● ● ● ● ●

●●

●●

●●

●● ● ● ● ● ● ● ●●●

●●

●●

●

●● ● ● ● ● ● ●

●●

● ●

●

●

●

●

● ● ● ● ● ● ●●●

●●

●●

●

● ● ● ● ● ●● ●●●

●

● ●

●

●●

● ● ● ● ● ● ●●●

●

●

●●

●●

● ● ● ● ● ●●●

●

●●

●●

●

● ● ● ● ● ● ●●

●●●

●

●●

●

● ● ● ● ● ● ●●●●

●

●

●

●●

●●

●●

●

●

●

●

●

● ●●

●●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●●

●●

●

●

●

●

●

●●

●●

●●

●

●

●

●●

●● ●

●●

●

●

●

●●

●●

●●

●

●

●

●

●●

●●

●●

●

●

●

●

●●

●●

●●

●

●

●

●

●

●●

● ●●

●

●

●

●

●●

●●

●●●

●

●

●

●●

●●

●●

●

●

●

●●

●

●●

●●●

●

●

●

●

●

●●

●●

●

●

●

●●

● ●

● ●●

●

●

●

●

●

●●

●●●

●

●

●

●

●

●

●

●

●

1 10 100 1000 10000

0.2

0.5

1.0

2.0

5.0

20.0

50.0

200.

0

object size in KB (logarithmic)

load

dur

atio

n in

sec

onds

(lo

garit

hmic

)

Figure 15: Load time in ms vs. object size in KB

4.2.10 Problems

Although the results for Tap using the Brazilian node in Sao Paulo weresatisfactory, the load times could have been significantly lower. A packettrace was analyzed to find the reason for the increased latency. It could beseen that even though the browser had posted its HTTP request to the proxy,the proxy would not forward it to the entry node. More than 200 ms lateran ACK arrived from the entry node and immediately afterwards the HTTPrequest was forwarded on to the entry node.

This problem is known as a temporary “deadlock”[8] due to interactionsbetween Nagle’s algorithm and TCP’s delayed acknowledgments [38]. Nagle’salgorithm is enabled on most TCP stacks by default, to prevent the trans-mission of many small packets by accumulating the data and sending it inbigger packets. TCP will send the packet only if either all previous packetshave been acknowledged or if there is enough data to fill a complete MTU.Delayed acknowledgments are another method for TCP implementations toprevent the transmission of small packets. The TCP stack will only acknowl-edge every second packet, or “piggyback” acknowledgments on data responsepackets. However, in order to avoid deadlocks, an acknowledgment may onlybe delayed a maximum duration of 500 ms according to the specification [38];after this timeout it must be sent anyway. BSD derived systems normally

54

4.3 Discussion

use a timeout of 200 ms [38], so does MS Windows [51].This was occurring because of an implementation detail: Although up to

eight Tap messages may be buffered in the application and written to theTCP stack all at once, notification messages informing the remote tunnelend of a closed socket were sent immediately. Firefox may use a maximum ofeight persistent connections to the proxy. On the client side, Tap associatesthe open browser sockets with the last Web server hostname they were usedfor. If the socket was used for a new connection, i. e., the hostname changed,Tap would immediately send a message to the exit node to close the corre-sponding connection to the Web server. This short message was sent beforethe actual HTTP request packet. Because the close message did not generatea response message on the exit node which could have been used for “piggy-backing” acknowledgments, TCP’s delayed acknowledgment mechanism heldback the TCP acknowledgment on the entry node and Nagle held back thetransmission of the new HTTP request, because it still had outstanding un-acknowledged packets, namely the close message. Finally, after the abovementioned timeout of 200 ms, the acknowledgment for the “close message”was sent by the entry node to the client PC, enabling the TCP stack on theclient PC to forward the HTTP request to the entry node.

Because this was not discovered until the final measurements had beenconducted, there was no time to rerun all the measurements. However, theprototype implementation was changed to fix this behavior and thus improveTap’s performance.

4.3 Discussion

Most importantly, the results show that Tap is able to deliver satisfactoryperformance. This applies to the initial loading of a Web site, as well as tosubsequent loading, where parts of the page can be served from the cache.Load times depend on the number of embedded objects as well as their size,and this is reflected by the results. Furthermore, the results show that thevariance of the load times is kept low, which makes it easier for users tobecome accustomed to Tap. Although geographical diversity of tunnel nodeshas a big influence on the load times, Tap’s performance remains adequate,even when international nodes are used. Congestion on tunnel nodes hasalso been evaluated and, depending on the type of congestion, it may haveinfluence on the load times. Congested uplinks add significant delays andvariance whereas congestion in the other direction has only very little in-fluence on the load time. This is due to the asymmetric nature of ADSL,i. e., the downstream speed is much higher than the upstream speed. Theoverhead induced by Tap has also been shown to be very small compared to

55

4 EVALUATION

the overhead added by the latency on the links between the tunnel nodes.

56

5 Conclusion

This chapter provides a brief summary of the thesis and lists some openproblems that need to be addressed to further improve Tap.

Summary The state-of-the-art anonymization system Tor is increasinglybeing used not only for anonymization purposes but also for circumventingcensorship by government-level firewalls. These firewalls, however, could alsobe used to block Tor itself, as Tor was designed for anonymity but not cen-sorship resistance or blocking resistance. This thesis has further shown thatthe quality of service in terms of latency offered by Tor varies significantly.This may lead to frustration of users that do not depend on anonymity butwere using it nevertheless to protect their privacy. Eventually these userswill stop to use Tor because they are not willing to sacrifice the performanceof their Internet connection for privacy. However, this type of user is veryimportant for an anonymity system, because their traffic is used to hide thetraffic of users really needing anonymity. Other solutions such as anonymiz-ing proxy servers exist, but none of them are well suited for anonymous,censorship-resistant, low-latency Internet access. There are also peer-to-peerbased systems, but most of them seem to be discontinued, probably due touser bases of insufficient size.

For this thesis, a novel solution, the Anonymous Peer-to-Peer Proxy(Tap), was designed, implemented, and tested; an anonymity system thatovercomes some of the shortcomings traditional, established systems have.The design goals in mind were anonymity, resistance to censorship, usabilityand scalability, without burdening any financial expenses neither on usersnor on the volunteers providing the network. These goals are met by com-bining multiple approaches into the solution presented by this thesis. Theonion-routing design of Tor is used to provide anonymity. In order to beable to circumvent censorship, it must also be guaranteed that the system isresistant to blocking from government-level firewalls. Tap’s solution for thisis to exchange the small set of well-known Tor servers for a much bigger setof peer-to-peer clients, enabling the network to scale with the number of itsusers. By using the client PCs to provide the anonymization service, it isspread across a big set of rapidly changing IP addresses and is therefore muchmore resistant to IP-based blocking by firewalls. In order to rapidly establisha user base of sufficient size, Tap is integrated into a popular peer-to-peerfile-sharing application. This has another advantage: The distributed hashtable infrastructure used by the file-sharing application is also used by Tapto discover other Tap nodes as well as their corresponding public keys.

Tap builds on the design of Tor, which means that some of the analyses

57

5 CONCLUSION

performed on Tor may be applied to Tap as well. Tap does not aim to providefull anonymity against all types of adversaries, but more at being a practicalsystem that is censorship resistant and protects a user’s anonymity againstcertain types of adversaries.

In this thesis, measurements for some popular Web sites were conducted,using German as well as international nodes for the anonymous tunnel. Theinfluence of other traffic on the tunnel nodes was also evaluated. The resultsshow that although Tap decreases Internet performance, it is still very wellsuited for low-latency Web browsing. Further investigation has to show ifthis performance can be kept up if Tap is actually deployed and used by alarger user base.

Outlook Although many of Tap’s features have already been incorporatedinto the prototype, additional work is needed to implement all of them. Thisincludes exit node protection measures, tunnel node selection schemes forgeographical diversity, seamless integration into the file-sharing application,different tunnel establishment schemes to better hide traffic, collaborationwith the Tor network, and so on.

The Tor project has realized the demand for a more censorship resistantdesign, too, and recently published a paper [20] which proposes some exten-sions to Tor in order to be more resistant to blocking. The main conceptintroduced are so called “bridges”, that behave somewhat similar to Tap en-try nodes. It would be interesting to investigate how a co-existence of Tapand the bridges could benefit the Tor network.

Another open problem is how to impede attacks based on traffic analysis,which apply to Tor as well [22]. A possible starting point could be to compressuser data, add small amounts of random padding and rechunk packets. Thiswould at least complicate attacks based on Web site fingerprints and packetsizes. Traffic generated by the file-sharing network could also be used toimpede traffic volume correlation and attacks based on inter-packet arrivaltimes [65]. Future research could focus on using file-sharing connections toforward Tap messages, thereby mixing file-sharing traffic and Tap traffic.This would require methods to prioritize Tap tunnels over data connectionsas well as modifications to the queuing system of the file-sharing application.Another possibility to hide the existence of Tap connections would be to makeTap’s tunnel establishments look like real HTTPS connection establishments,making it hard for firewalls to distinguish them from each other.

58

6 Appendix

The appendix provides some listings, acknowledgments, and a German sum-mary.

6.1 Listings

Listing 1: SMTP abuse with Tap

echo −e ”GET http :// mail . math . tu−b e r l i n . de :25/ HTTP/1.0\nHELO ben\nMAIL FROM:<bar@foo . com>\nRCPT TO:<foo@bar . com>\nDATA\nHel lo Ben\n .\nQUIT\n\n” | ncl o c a l h o s t 8000 −w 1

220 mail . math .TU−Ber l i n .DE ESMTP Sendmail8 . 1 3 . 7 / 8 . 1 3 . 3 ; Mon, 15 Dec 2008 16 : 34 : 34 +0100 (MET)

500 5 . 5 . 1 Command unrecognized : ”GET / HTTP/ 1 . 0 ”250 mail . math .TU−Ber l i n .DE Hel lo xyz . math .TU−Ber l i n .DE

[ 1 3 0 . 1 4 9 . x . x ] , p l ea sed to meet you250 2 . 1 . 0 <bar@foo . com > . . . Sender ok250 2 . 1 . 5 <foo@bar . com > . . . Rec ip i ent ok354 Enter mail , end with ”. ” on a l i n e by i t s e l f250 2 . 0 . 0 mBFFYYT0006601 Message accepted f o r d e l i v e r y221 2 . 0 . 0 mail . math .TU−Ber l i n .DE c l o s i n g connect ion

Listing 2: SSH over Tap with Corkscrew

ssh −o ProxyCommand=”corkscrew l o c a l h o s t 8000 %h %p”root@foo . bar

59

6 APPENDIX

6.2 Acknowledgments

I would like to thank Professor Anja Feldmann for letting me write this thesisat her research group, Gregor Maier and Bernhard Ager for their assistanceand feedback, Stefan Sechelmann for his support, feedback, and patience, mymom for help with the English language, and everybody else who supportedme while I was writing this thesis.

60

6.3 Deutsche Zusammenfassung

6.3 Deutsche Zusammenfassung

Die meisten Systeme, die eine anonyme Benutzung des Internet ermogli-chen, basieren auf einer kleinen Anzahl hintereinander geschalteter, Proxy-ahnlicher Server, sogenannter Mix-nets. Herkommliche Systeme bestehen meistaus einer verhaltnismaßig kleinen Anzahl an Servern, von denen die Clientseinige auswahlen, um mit ihrer Hilfe einen anonymen Tunnel aufzubauen.Diese Systeme bieten allerdings nur einen maßigen Schutz vor Zensurmaß-nahmen durch Regierungen, da die Systeme selbst meist leicht in den ent-sprechenden Firewalls der ISPs blockiert werden konnen. Weitere Nachteilesind eine schlechte Skalierbarkeit sowie ein schwacher Schutz vor Angreifern,die mit Hilfe von Analysen des Datenverkehrs versuchen, die Anonymitat zubrechen. Das am weitesten verbreitete und benutzte System dieser Art istTor. Andererseits gibt es ein paar neue Ansatze, die diese Nachteile zu um-gehen versuchen, indem sie eine Peer-to-Peer-Architektur wahlen. Allerdingsscheint keines dieser Systeme uber eine nennenswerte Nutzergemeinde zuverfugen, womit sie fur eine funktionsfahige Anonymisierung nicht in Fragekommen.

Die hier vorgestellte Losung, der Anonyme Peer-to-Peer Proxy (Tap),wurde mit dem Ziel entwickelt, nicht anfallig zu sein fur die oben genann-ten Probleme der existierenden Losungen. Tap setzt auf das Design undKnow-how von Tor, benutzt aber statt des Client-Server-Modells einen Peer-to-Peer-basierten Ansatz um das anonymisierende Overlay-Netzwerk aufzu-bauen. Damit wird von Tap ein Großteil der Nutzer auch zum Bereitstellendes Anonymisierungsdienstes verwendet. Aufgrund der großen Anzahl tag-lich wechselnder Knoten ist das Tap Netzwerk technisch viel besser vor IP-basiertem Blockieren durch ISPs geschutzt. Diese Fluktuation der den Dienstanbietenden Knoten, gepaart mit der geographischen Verteilung, erschwertes Angreifern erheblich, den Datenverkehr aller beteiligten Knoten zu uber-wachen und zu analysieren. Außerdem besitzt der Peer-to-Peer Ansatz nochden Vorteil, dass er sehr gut skaliert, da mit der Anzahl der Nutzer auch dieAnzahl derer ansteigt, die den Dienst anbieten.

Um das Problem einer zu geringen Nutzergemeinde zu vermeiden, wirdTap in einen popularen Peer-to-Peer Filesharing-Client integriert. Da derenBenutzer dazu neigen, relativ zugig auf die jeweils aktuellste Version der Ap-plikation umzusteigen, konnte innerhalb kurzer Zeit ein Tap Netzwerk mittausenden von Nutzern entstehen. Diese Integration ermoglicht es Tap au-ßerdem, auf zentrale Verzeichnisserver, wie sie von Tor verwendet werden,zu verzichten. Stattdessen benutzt Tap Mechanismen des Filesharing Pro-gramms um andere Knoten kennenzulernen, sowie deren verteilte Hash-Liste(DHT) fur die Distribution der benotigten kryptographischen Schlussel.

61

References

[1] AFP. Web could get you killed, October 2008. URL http://

technology.iafrica.com/news/technology/1010080.htm.

[2] Deutsche Telekom AG. Fastpath fur DSL, 2008. URLhttp://www.t-home.de/Katalog-PK-N-FastPath%20f%C3%BCr%

20DS-CCID-cYIKmCI1DRIAAAEZArRST70g.

[3] The aMule Project. aMule, 2008. URL http://www.amule.org/.

[4] David Bandurski. Brutal killing of (citizen journalist) Wei Wenhuaunderscores the evils of China’s ”urban management” system, January2008. URL http://cmp.hku.hk/2008/01/10/814/.

[5] Kai Billen. Verfolgung von Tor Ausgangsrouter Betreibern, 2008. URLhttp://hp.kairaven.de/bigb/asurf8.html.

[6] Rene Brunner. A performance evaluation of the Kad-protocol. Master’sthesis, Lehrstuhl fur Praktische Informatik IV, Universitat Mannheim,November 2006. URL http://www.eurecom.fr/~btroup/BThesis/

MasterThesisBrunner.pdf.

[7] David Chaum. Untraceable electronic mail, return addresses, and digitalpseudonyms. Communications of the ACM, 24(2):84–88, February 1981.

[8] Stuart Cheshire. TCP performance problems caused by interaction be-tween Nagle’s algorithm and delayed ACK, 2008. URL http://www.

stuartcheshire.org/papers/NagleDelayedAck/.

[9] Richard Clayton, Steven J. Murdoch, and Robert N. M. Watson. Ig-noring the great firewall of China. 6th Workshop on Privacy EnhancingTechnologies, June 2006.

[10] Lorenzo Colitti and Philip Chee. Flashblock 1.5.7, 2008. URL https:

//addons.mozilla.org/de/firefox/addon/433.

[11] Greasemonkey Community. Greasemonkey user scripts, 2008. URLhttp://userscripts.org.

[12] Tor Community. Tor-Handbuch. URL http://www.tor.de/wiki/

Tor-Handbuch#Client_Optionen.

[13] Micah Cowan and Hrvoje Niksic. GNU WGet, 2008. URL http://www.

gnu.org/software/wget.

62

http://technology.iafrica.com/news/technology/1010080.htm

http://technology.iafrica.com/news/technology/1010080.htm

http://www.t-home.de/Katalog-PK-N-FastPath%20f%C3%BCr%20DS-CCID-cYIKmCI1DRIAAAEZArRST70g

http://www.t-home.de/Katalog-PK-N-FastPath%20f%C3%BCr%20DS-CCID-cYIKmCI1DRIAAAEZArRST70g

http://www.amule.org/

http://cmp.hku.hk/2008/01/10/814/

http://hp.kairaven.de/bigb/asurf8.html

http://www.eurecom.fr/~btroup/BThesis/MasterThesisBrunner.pdf

http://www.eurecom.fr/~btroup/BThesis/MasterThesisBrunner.pdf

http://www.stuartcheshire.org/papers/NagleDelayedAck/

http://www.stuartcheshire.org/papers/NagleDelayedAck/

https://addons.mozilla.org/de/firefox/addon/433


http://userscripts.org

http://www.tor.de/wiki/Tor-Handbuch#Client_Optionen

http://www.tor.de/wiki/Tor-Handbuch#Client_Optionen

http://www.gnu.org/software/wget

http://www.gnu.org/software/wget

REFERENCES

[14] Curt. Iran now to kill bloggers - follow that, China!, July2008. URL http://committeetoprotectbloggers.org/2008/07/04/

iran-now-to-kill-bloggers-follow-that-china/.

[15] Joan Daemen and Vincent Rijmen. The Design of Rijndael. AES: TheAdvanced Encryption Standard. Springer, 2002.

[16] Wei Dai. Crypto++ library 5.5.2, 2007. URL http://www.cryptopp.

com.

[17] Privoxy Developers. Privoxy, 2008. URL http://www.privoxy.org/.

[18] Roger Dingledine. Tor and China, design of a blocking-resistantanonymity system. 23rd Chaos Communication Congress, 2006. URLhttp://events.ccc.de/congress/2006/Fahrplan/attachments/

1237-Tor_and_China-23C3-1444-slides.pdf.

[19] Roger Dingledine and Nick Mathewson. Anonymity loves company: Us-ability and the network effect. 2006. URL http://www.freehaven.

net/anonbib/cache/usability:weis2006.pdf.

[20] Roger Dingledine and Nick Mathewson. Design of a blocking-resistantanonymity system. February 2008. URL https://svn.torproject.

org/svn/tor/trunk/doc/design-paper/blocking.pdf.

[21] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor: Thesecond-generation onion router. 2004. URL https://svn.torproject.

org/svn/tor/trunk/doc/design-paper/tor-design.pdf.

[22] Roger Dingledine, Nick Mathewson, and Paul Syverson. Chal-lenges in deploying low-latency anonymity. 2005. URLhttps://svn.torproject.org/svn/tor/trunk/doc/design-paper/

challenges.pdf.

[23] d.paysafecard.com GmbH. paysafecard, 12 2008. URL http://www.

paysafecard.com/.

[24] Nils Durner, Nathan S. Evans, and Christian Grothoff. Unerkannt,Anonymisierende Peer-to-Peer-Netze im Uberblick. iX Magazin fur pro-fessionelle Informationstechnik, 9:88–94, 2008.

[25] The eMule Project. eMule, 2008. URL http://www.emule-project.

net/.

63

http://committeetoprotectbloggers.org/2008/07/04/iran-now-to-kill-bloggers-follow-that-china/

http://committeetoprotectbloggers.org/2008/07/04/iran-now-to-kill-bloggers-follow-that-china/

http://www.cryptopp.com

http://www.cryptopp.com

http://www.privoxy.org/

http://events.ccc.de/congress/2006/Fahrplan/attachments/1237-Tor_and_China-23C3-1444-slides.pdf

http://events.ccc.de/congress/2006/Fahrplan/attachments/1237-Tor_and_China-23C3-1444-slides.pdf

http://www.freehaven.net/anonbib/cache/usability:weis2006.pdf

http://www.freehaven.net/anonbib/cache/usability:weis2006.pdf

https://svn.torproject.org/svn/tor/trunk/doc/design-paper/blocking.pdf

https://svn.torproject.org/svn/tor/trunk/doc/design-paper/blocking.pdf

https://svn.torproject.org/svn/tor/trunk/doc/design-paper/tor-design.pdf

https://svn.torproject.org/svn/tor/trunk/doc/design-paper/tor-design.pdf

https://svn.torproject.org/svn/tor/trunk/doc/design-paper/challenges.pdf

https://svn.torproject.org/svn/tor/trunk/doc/design-paper/challenges.pdf

http://www.paysafecard.com/

http://www.paysafecard.com/

http://www.emule-project.net/

http://www.emule-project.net/

REFERENCES

[26] Nick Feamster and Roger Dingledine. Jurisdictional diversity inanonymity networks. Workshop on Privacy in the Electronic Society,2004.

[27] Mozilla Foundation. Mozilla Firefox about:config entries, 2008. URLhttp://kb.mozillazine.org/About:config_Entries.

[28] Michael J. Freedman and Robert Morris. Tarzan: A peer-to-peeranonymizing network layer. In Proceedings of the 9th ACM Conferenceon Computer and Communications Security (CCS 2002), Washington,D.C., November 2002. URL http://pdos.csail.mit.edu/tarzan/

docs/tarzan-ccs02.pdf.

[29] Unabhangiges Landeszentrum fur Datenschutz Schleswig-Holstein.Pressemitteilung: AN.ON gewahrleistet auch weiterhin Anonymitat,August 2003. URL https://www.datenschutzzentrum.de/material/

themen/presse/anonip.htm.

[30] Unabhangiges Landeszentrum fur Datenschutz Schleswig-Holstein.Pressemitteilung: AN.ON erneut gegen Bundeskriminalamt erfolg-reich, November 2003. URL https://www.datenschutzzentrum.de/

material/themen/presse/anonip4.htm.

[31] JonDos GmbH. Transparent client integration of anti-censorship, 2008.URL https://www.jondos.de/en/development.

[32] JonDos GmbH. Jondos, 2008. URL https://www.jondos.de/.

[33] David Goldschlag, Michael Reed, and Paul Syverson. Onion routing foranonymous and private internet connections. Communications of theACM, 42(2), February 1999. URL http://www.onion-router.net/

Publications.html.

[34] David M. Goldschlag, Michael G. Reed, and Paul F. Syverson. HidingRouting Information. In R. Anderson, editor, Proceedings of Informa-tion Hiding: First International Workshop, pages 137–150. Springer-Verlag, LNCS 1174, May 1996. URL http://www.onion-router.net/

Publications/IH-1996.pdf.

[35] The Firebug Working Group. Firebug, 2008. URL http://getfirebug.

com.

[36] Sven Hansen. Dissidenten mussen verruckt sein. Le Monde diploma-tique, 1:80–84, 2007. URL http://www.monde-diplomatique.de/pm/

.china_psychiatrie.

64

http://kb.mozillazine.org/About:config_Entries

http://pdos.csail.mit.edu/tarzan/docs/tarzan-ccs02.pdf

http://pdos.csail.mit.edu/tarzan/docs/tarzan-ccs02.pdf

https://www.datenschutzzentrum.de/material/themen/presse/anonip.htm

https://www.datenschutzzentrum.de/material/themen/presse/anonip.htm

https://www.datenschutzzentrum.de/material/themen/presse/anonip4.htm

https://www.datenschutzzentrum.de/material/themen/presse/anonip4.htm

https://www.jondos.de/en/development

https://www.jondos.de/

http://www.onion-router.net/Publications.html

http://www.onion-router.net/Publications.html

http://www.onion-router.net/Publications/IH-1996.pdf

http://www.onion-router.net/Publications/IH-1996.pdf

http://getfirebug.com

http://getfirebug.com

http://www.monde-diplomatique.de/pm/.china_psychiatrie

http://www.monde-diplomatique.de/pm/.china_psychiatrie

REFERENCES

[37] HanseNet. Alice Fun Preisliste, 2007. URL https://www.alice-dsl.

de/kundencenter/export/de/download/preislisten/preise_

alicefun_n.pdf.

[38] John Heidemann. Performance interactions between P-HTTP andTCP implementations. ACM Computer Communication Review, 27(2):65–73, April 1997. URL http://www.isi.edu/~johnh/PAPERS/

Heidemann97a.html.

[39] The Sydney Morning Herald. The hack of the year, 2007. URLhttp://www.smh.com.au/news/security/the-hack-of-the-year/

2007/11/12/1194766589522.html.

[40] Anonymizer Inc. Anonymizer, 2008. URL http://www.anonymizer.

com.

[41] Eric H. Jung. FoxyProxy Firefox add-on, 2008. URL https://addons.

mozilla.org/de/firefox/addon/2464.

[42] Thomas Kernen. traceroute.org, 2008. URL http://www.traceroute.

org/.

[43] Joseph B. Kowalski and Kasimir Gabert. Tor network status, 2008. URLhttp://anonymizer.blutmagie.de:2505/index.php.

[44] D. Kristol and L. Montulli. HTTP State Management Mechanism. RFC2965 (Proposed Standard), October 2000. URL http://www.ietf.org/

rfc/rfc2965.txt.

[45] Anthony Lieuallen, Aaron Boodman, and Johan Sundstrom. Grease-monkey, 2008. URL http://www.greasespot.net.

[46] Helger Lipmaa, Phillip Rogaway, and David Wagner. CTR-modeencryption, 9 2000. URL http://www.cs.ucdavis.edu/~rogaway/

papers/ctr.pdf.

[47] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, and R. Wheeler.A Method for Transmitting PPP Over Ethernet (PPPoE). RFC 2516(Informational), February 1999. URL http://www.ietf.org/rfc/

rfc2516.txt.

[48] Art Manion. HTTP proxy default configurations allow arbitrary TCPconnections. US-CERT Vulnerability Note, (150227), 2005. URL http:

//www.kb.cert.org/vuls/id/150227.

65

https://www.alice-dsl.de/kundencenter/export/de/download/preislisten/preise_alicefun_n.pdf



http://www.isi.edu/~johnh/PAPERS/Heidemann97a.html

http://www.isi.edu/~johnh/PAPERS/Heidemann97a.html

http://www.smh.com.au/news/security/the-hack-of-the-year/2007/11/12/1194766589522.html

http://www.smh.com.au/news/security/the-hack-of-the-year/2007/11/12/1194766589522.html

http://www.anonymizer.com

http://www.anonymizer.com



http://www.traceroute.org/

http://www.traceroute.org/

http://anonymizer.blutmagie.de:2505/index.php

http://www.ietf.org/rfc/rfc2965.txt


http://www.greasespot.net

http://www.cs.ucdavis.edu/~rogaway/papers/ctr.pdf

http://www.cs.ucdavis.edu/~rogaway/papers/ctr.pdf



http://www.kb.cert.org/vuls/id/150227

http://www.kb.cert.org/vuls/id/150227

REFERENCES

[49] Petar Maymounkov and David Mazieres. Kademlia: A peer-to-peerinformation system based on the xor metric, 2002. URL http://www.

cs.rice.edu/Conferences/IPTPS02/109.pdf.

[50] Benjamin Michele. Tap application download, December 2008. URLhttp://cs.tu-berlin.de/~bmichele/tap.

[51] Microsoft. New registry entry for controlling the TCP acknowledgment(ACK) behavior in Windows XP and in Windows Server 2003, 2007.URL http://support.microsoft.com/?scid=kb%3Ben-us%3B328890.

[52] Steven Murdoch and George Danezis. Low-cost traffic analysis of Tor.IEEE Symposium on Security and Privacy, 2005.

[53] J. Postel. Transmission Control Protocol. RFC 793 (Standard), Septem-ber 1981. URL http://www.ietf.org/rfc/rfc793.txt. Updated byRFCs 1122, 3168.

[54] The JMeter Project. Apache JMeter, 2008. URL http://jakarta.

apache.org/jmeter/.

[55] The Tor Project. Tor: Documentation, 2008.

[56] The Tor Project. Tor - overview. URL http://www.torproject.org/

overview.html.en.

[57] Dan Rayburn. CNN, Netflix and NFL use level 3 for content de-livery, December 2008. URL http://seekingalpha.com/article/

110598-cnn-netflix-and-nfl-use-level-3-for-content-delivery.

[58] Marc Rennhard and Bernhard Plattner. Introducing MorphMix: peer-to-peer based anonymous internet usage with collusion detection. InWPES ’02: Proceedings of the 2002 ACM workshop on Privacy in theElectronic Society, pages 91–102, New York, NY, USA, 2002. ACM.ISBN 1-58113-633-1.

[59] Marc Rennhard and Bernhard Plattner. Practical anonymity for themasses with MorphMix. In Financial Cryptography, volume 3110/2004of Lecture Notes in Computer Science, pages 233–250. Springer, 2004.

[60] Gerhard Rieger. Socat, 2008. URL http://www.dest-unreach.org/

socat/.

66

http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf

http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf

http://cs.tu-berlin.de/~bmichele/tap

http://support.microsoft.com/?scid=kb%3Ben-us%3B328890


http://jakarta.apache.org/jmeter/

http://jakarta.apache.org/jmeter/

http://www.torproject.org/overview.html.en

http://www.torproject.org/overview.html.en

http://seekingalpha.com/article/110598-cnn-netflix-and-nfl-use-level-3-for-content-delivery

http://seekingalpha.com/article/110598-cnn-netflix-and-nfl-use-level-3-for-content-delivery

http://www.dest-unreach.org/socat/

http://www.dest-unreach.org/socat/

REFERENCES

[61] Christiane Schulzki-Haddouti. Heise-Online - 18.08.03 - Nicht mehr ganzanonym: Anonymisier-Dienst JAP protokolliert Zugriffe, August 2003.URL http://www.heise.de/newsticker/meldung/print/39508.

[62] Gunter Schafer. Netzsicherheit: Algorithmische Grundlagen und Pro-tokolle. dpunkt.verlag, Heidelberg, 2003.

[63] Jochen Schonfeld. Lan emulation (LANE), 1997. URL http://www.

tkn.tu-berlin.de/curricula/ss97/bnt97/schoen.html.

[64] Heise Security. Anonymisierungsnetz Tor ”abgephisht”,September 2007. URL http://www.heise.de/newsticker/

Anonymisierungsnetz-Tor-abgephisht--/meldung/95770.

[65] Vitaly Shmatikov and Ming-Hsiu Wang. Timing analysis in low-latencymix networks: attacks and defenses. In Lecture Notes in ComputerScience, volume 4189, pages 18–33. Springer, September 2006. URLhttp://www.cs.utexas.edu/~shmat/shmat_esorics06.pdf.

[66] William Stallings. Data and Computer Communication. Prentice Hall,7 edition, 2004.

[67] Swan. Chinese blogger murdered by Cheng Guan authorities, January2008. URL http://www.associatedcontent.com/article/535387/

chinese_blogger_murdered_by_cheng_guan.html?cat=47.

[68] Parisa Tabriz and Nikita Borisov. Breaking the collusion detection mech-anism of MorphMix. 6th Workshop on Privacy Enhancing Technolo-gies, 2006. URL http://petworkshop.org/2006/preproc/preproc_

21.pdf.

[69] Tagesschau. Chinesischer Blogger in die Psychiatrie gesteckt, August2007. URL http://www.tagesschau.de/ausland/meldung487286.

html.

[70] JAP Team. Technischer Hintergrund von JAP, July 2001. URL http:

//anon.inf.tu-dresden.de/JAPTechBgPaper.pdf.

[71] Christoph Wachter and Mathias Jud. Picidae, 2008. URL http://www.

picidae.net.

[72] Peng Wang, James Tyra, Eric Chan-Tin, Tyson Malchow, Denis FooKune, Nicholas Hopper, and Yongdae Kim. Attacking the Kad network.SecureComm, 2008. URL http://www-users.cs.umn.edu/~hopper/

kad_attack_securecomm.pdf.

67

http://www.heise.de/newsticker/meldung/print/39508

http://www.tkn.tu-berlin.de/curricula/ss97/bnt97/schoen.html

http://www.tkn.tu-berlin.de/curricula/ss97/bnt97/schoen.html

http://www.heise.de/newsticker/Anonymisierungsnetz-Tor-abgephisht--/meldung/95770

http://www.heise.de/newsticker/Anonymisierungsnetz-Tor-abgephisht--/meldung/95770

http://www.cs.utexas.edu/~shmat/shmat_esorics06.pdf

http://www.associatedcontent.com/article/535387/chinese_blogger_murdered_by_cheng_guan.html?cat=47

http://www.associatedcontent.com/article/535387/chinese_blogger_murdered_by_cheng_guan.html?cat=47

http://petworkshop.org/2006/preproc/preproc_21.pdf

http://petworkshop.org/2006/preproc/preproc_21.pdf

http://www.tagesschau.de/ausland/meldung487286.html

http://www.tagesschau.de/ausland/meldung487286.html

http://anon.inf.tu-dresden.de/JAPTechBgPaper.pdf

http://anon.inf.tu-dresden.de/JAPTechBgPaper.pdf

http://www.picidae.net

http://www.picidae.net

http://www-users.cs.umn.edu/~hopper/kad_attack_securecomm.pdf

http://www-users.cs.umn.edu/~hopper/kad_attack_securecomm.pdf

REFERENCES

[73] Wikipedia. Breitband-Zugangsserver, 2008. URL http://de.

wikipedia.org/wiki/DSL-AC.

[74] Wikipedia. Asymmetric Digital Subscriber Line (ADSL), 2008. URLhttp://de.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_

Line.

[75] Wikipedia. Ad serving, 2008. URL http://en.wikipedia.org/wiki/

Ad_serving.

[76] Wikipedia. File sharing. URL http://en.wikipedia.org/wiki/File_

sharing#Third_P2P-Generation:_indirect_and_encrypted.

[77] Wikipedia. DSLAM, 2008. URL http://de.wikipedia.org/wiki/

DSLAM.

[78] WIkipedia. HTTP pipelining, 2008. URL http://en.wikipedia.org/

wiki/HTTP_pipelining.

[79] Wikipedia. Interleaving, 2008. URL http://de.wikipedia.org/wiki/

Interleaving.

[80] Wikipedia. Kademlia implementations, 2008. URL http://en.

wikipedia.org/wiki/Kademlia#Implementations.

[81] Wikipedia. Homepage, 2008. URL http://en.wikipedia.org/wiki/

Homepage.

[82] Wikipedia. Mix network, 2008. URL http://en.wikipedia.org/wiki/

Mix-net.

[83] Wikipedia. Proxy server, 2008. URL http://en.wikipedia.org/wiki/

Proxy_server.

[84] Wikipedia. Boxplot, 2008. URL http://en.wikipedia.org/wiki/

Box_plot.

[85] Wikipedia. Content Delivery Network (CDN), 2008. URL http://en.

wikipedia.org/wiki/Content_delivery_network.

[86] Sebastian Wolfgarten. Investigating large-scale internet con-tent filtering. Master’s thesis, Dublin City University, Ire-land, August 2006. URL http://www.devtarget.org/downloads/

dcu-mssf-2005-wolfgarten-filtering.pdf.

68

http://de.wikipedia.org/wiki/DSL-AC

http://de.wikipedia.org/wiki/DSL-AC

http://de.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line

http://de.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line

http://en.wikipedia.org/wiki/Ad_serving

http://en.wikipedia.org/wiki/Ad_serving

http://en.wikipedia.org/wiki/File_sharing#Third_P2P-Generation:_indirect_and_encrypted

http://en.wikipedia.org/wiki/File_sharing#Third_P2P-Generation:_indirect_and_encrypted

http://de.wikipedia.org/wiki/DSLAM

http://de.wikipedia.org/wiki/DSLAM

http://en.wikipedia.org/wiki/HTTP_pipelining

http://en.wikipedia.org/wiki/HTTP_pipelining

http://de.wikipedia.org/wiki/Interleaving

http://de.wikipedia.org/wiki/Interleaving

http://en.wikipedia.org/wiki/Kademlia#Implementations

http://en.wikipedia.org/wiki/Kademlia#Implementations

http://en.wikipedia.org/wiki/Homepage

http://en.wikipedia.org/wiki/Homepage

http://en.wikipedia.org/wiki/Mix-net

http://en.wikipedia.org/wiki/Mix-net

http://en.wikipedia.org/wiki/Proxy_server

http://en.wikipedia.org/wiki/Proxy_server

http://en.wikipedia.org/wiki/Box_plot

http://en.wikipedia.org/wiki/Box_plot

http://en.wikipedia.org/wiki/Content_delivery_network

http://en.wikipedia.org/wiki/Content_delivery_network

http://www.devtarget.org/downloads/dcu-mssf-2005-wolfgarten-filtering.pdf

http://www.devtarget.org/downloads/dcu-mssf-2005-wolfgarten-filtering.pdf

REFERENCES

[87] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Connection Protocol.RFC 4254 (Proposed Standard), January 2006. URL http://www.ietf.

org/rfc/rfc4254.txt.

[88] Jonathan Zittrain and Benjamin Edelman. Internet filtering in China.IEEE Computing, 7:70–77, 2003.

69



using onion-routing in well-established p2p networks to ......anonymity for purposes of anonymity,...

Documents