Towards an anonymous Domain Name System

IT-Security

2nd Bachelor´s Thesis

Towards an Anonymous Domain Name System

Written within the degree program „IT-Security“ at the University of Applied Sciences Sankt Pölten

by

Daniel Haslinger 0810410008

under guidance of FH Prof. Dipl. Ing. Bernhard R. Fischer

Sankt Poelten, August 15, 2011

The author grants the right to use this thesis for educational purposes and research, as well as the right to use it for advertising (e.g. project vernissages, in publications, on their website), to the University of Applied Sciences Sankt Poelten GmbH, as long as the author is named as originator. Any kind of commercial application/usage requires an additional agreement between the author and the University of Applied Sciences Sankt Poelten GmbH. Additionally, this thesis is released under Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Der Autor r¨ aumt der Fachhochschule Sankt Poelten GmbH das Recht ein, die Bachelorarbeit f¨ ur Lehre- und Forschungst¨ atigkeiten zu verwenden und damit zu werben (zB. bei Projektevernissagen, in Publikationen, auf der Website) wobei der Autor als Urheber zu nennen ist. Jegliche kommerzielle Verwertung/Nutzung bedarf einer weiteren Vereinbarung zwischen dem Autor und der Fachhochschule Sankt Poelten GmbH. Allgemein unterliegt diese Arbeit der Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

IT-Security

Declaration I hereby certify that

• I have written this thesis independently, solely based on the literature and tools that I cited appropriately without using any forbidden tools or methods. • I never brought this thesis for evaluation before another - neither national nor international - appraiser, as well as never handed it in for an exam. • the version of this thesis corresponds to the version assessed by the appraiser.

Ich versichere, dass

• ich diese Bachelorarbeit selbständig verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich sonst keiner unerlaubten Hilfsmittel bedient habe. • ich dieses Bachelorarbeitsthema bisher weder im Inland noch im Ausland einem Begutachter/einer Begutachterin zur Beurteilung oder in irgendeiner Form als Pr¨ ufungsarbeit vorgelegt habe. • diese Arbeit mit der vom Begutachter/von der Begutachterin beurteilten Arbeit u ¨bereinstimmt.

Sankt Poelten, August 15th, 2011 Daniel Haslinger

Daniel Haslinger, 0810410008

iii

IT-Security

“Liberty is not the power of doing what we like, but the right of being able to do what we ought” John Emerich Edward Dalberg-Acton, 1st Baron Acton


v

IT-Security

Abstract The era of information, starting in the late 70ies, drives the world wide demand for fast and ubiquituous communication. Reams of networks got connected together and formed what we today call the Internet, providing a valuable foundation for business and information-related industries, as well as an integral part of most individuals daily life. In this era information is one of the most important and precious resources, but there are more informations exchanged than most users do actually perceive when they use information technology. Every individual participating in such networks may run the risk of having his communication wiretapped, so techniques were developed to protect the transmitted data. Unfortunately the communication channel itself may reveal sensitive information to an eavesdropper. Originator, forwarder- and recipient identity, communication profiles and behaviour analysis are just a few of the informations that may be derived from observing individuals. Even though there are technologies that aim to protect these users from revealing their identity, fundamental network services beyond these technologies´ influence may leak information through side channels. This thesis addresses potential information leaks of the domain name service in combination with using privacy networks like e.g. Tor. It aims to protect the users identity while at the same time maintaining compatibility to the existing name server infrastructure.


vi

IT-Security

Contents 1 Introduction

2

1.1

Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.2

Outline of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2 Anonymity

6

2.1

Definition of anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2

The importance of anonymity today . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

The drawbacks of anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3 Technical background

11

3.1

Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.2

Darknets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.3

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4 Anonymization of DNS

22

4.1

The hosts file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.2

Possible Tunneling techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.3

Anonymous Name Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.4

aeon: Anonymity Encapsulation Over Nameservice . . . . . . . . . . . . . . . .

27

4.5

Design considerations regarding covert channels . . . . . . . . . . . . . . . . . .

34

4.6

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5 Conclusion

36

6 Appendix

a

6.1

DNS Packet: Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

a

6.2

DNS Packet: Query Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . .

c

6.3

DNS Packet: Resource Record Structure . . . . . . . . . . . . . . . . . . . . . .

c

7 Acronyms

d

Literature

f


1

IT-Security

Chapter 1

Introduction The Internet is considered to be a place where people all around the world that have access to it can find accurate and actual information. It began as a robust and scaleable communication technology for the U.S. Department of Defense, gained worth for science and international collaboration and finally turned out to be one of the most important driving forces for the economy today. The decentralized and unregulated character allowed every individual not only to join the network, but to broadcast information to a world wide audience in no time. A form of broadcast that eludes itself from any type of control that has been observed with anxiety by various governments and leaders. Several countries decided to invent digital censorship to avoid regime critical informations or independent news coverage from being consumed by their citizens, as well as to prevent unfavourable informations from leaving the countries. Some of them even monitor their citizens online activities so that the users attempt to gather a certain type of information can be identified for later investigations. Organized crime, copyright infrightment, deception and child pornography are high-visibility reasons for monitoring online activities - at least these are the main reasons provided by governments to defend their surveillance and data retention plans. The saying “Nothing to hide, nothing to fear” seems to serve as a killer argument as well as the credo of digital politics of the 21st century. In eastern regions digital oppression happens more frequently than in western countries [1] [2]. Western governments use this fact to focus their citizens´ attention to these oppressed countries while at the same time they are implementing similar technologies in disguise of security. Even if they would feel committed to take a stand against this form of digital oppression: Most of the surveillance technologies used in oppressed regions were developed and exported by western countries [3]. Wealth seems to be superior to freedom. For centuries people fought for their rights for independence and privacy. Today, terror seems to be the justification to dismantle these rights in public. The fear spreaded by media and authorities is instrumented to control public opinion and to tighten the grid of surveillance.


2

IT-Security

Twenty-seven years behind time, the “Orwellian society”1 sneaks into existence through data retention, cell phone positioning and the german federal trojan horse. The “smarter” our (especially mobile-) technology gets, the more information about us, our habits and our life is available to law enforcement - literally on demand. Although politicians, law enforcement and administrations are expected to act responsibly with the information gathered, we should not forget to maintain a level of sane suspiciousness. The british historian Sir John Dalberg-Acton once stated: “Power tends to corrupt; absolute power corrupts absolutely”. While this might sound pessimistic and distrustful, it points out a very important problem with personal information and data retention: as soon as a government introduces filtering or surveillance on a large scale - even with best intentions in mind - the resulting data will be available to any government that might take over control afterwards. The political orientation might change and so will the usage of the collected information. The general public will loose control of any data gathered through such systems. To maintain the idea of a global and free information network, a number of anonymization technologies were developed. This thesis primarily covers so called darknets, but it can be related to any other online anonymization technology. Darknets are anonymization networks that aim to maintain compatibility to the existing network infrastructure and allow their participants to use software they are familiar with (e.g. Webbrowsers, eMail clients, ...). The users are kept within a separated network that guarantees anonymity and confidentiality [4]. Two examples for such networks are Tor and I2P. Both of them are able to create an anonymous network within the Internet. The anonymity for individuals within such networks is related to the number of participants that are actively using the service. Therefore, those networks are constantly trying to attract more users to join them. Besides anonymity, also the speed of those networks is directly related to the number of active users, which makes it hard for new solutions to get their services bootstrapped. Another problem is the number of existing solutions and their diversity. The users are spreading across a growing number of anonymization networks which reduces the number of participants that are effectively supporting each individual network. Most users use a specific service rather than several at the same time. The incompatibility between those networks forces each of them into eking out an existence as marginal groups with small isolated user bases [5]. Another reason why anonymization solutions are not widely used is that most of the users on the Internet do not even know that their privacy might be compromised. Most who do are persuaded of the fact that their communication and their data is not attractive or important enough to be eavesdropped at all. But even if they can be convinced to use anonymization technology for all aspects of their online communication, most of them would not be able to achieve this. Anonymization solutions are often complicated and not easy to understand for 1

referring to George Orwell’s fiction “1984”


3

IT-Security

the average user. A common problem is how to address information within a darknet. Either within a darknet or the plain internet - addressing is not an easy task since the user might have to deal with complicated locators. Looking at networks in general, they can be compared to telephone networks. The IP address, which is the Internet pendant to a telephone number, is used to address individual hosts within networks. To minimize the effort of memorizing reams of telephone numbers, telephone books allowed looking up numbers by names and areas. To allow the same convenient method of looking up destinations by nicenames within networks, the Domain Name System was invented. It works similar to the directory assistance: A known number is dialed by the caller and asked for another number by telling the name of the desired telephonee. While doing the same on the Internet, a known IP address is contacted and asked for the IP address of the desired target host. For the world wide web it is one of the key factors for easy access to information, but for anonymization networks it is a component that is highly vulnerable to side channel attacks. The problem with these directories is the lack of confidentiality. Even though the telephone call to the telephonee is encrypted, the directory assistance knows who was called - as well as any eavesdropper on the line. Similar considerations apply to the Domain Name System as it features no confidentiality or anonymity measures. This may reveal sensitive information for eavesdroppers and exposed DNS users to a wide range of attacks during the last years [6]. At the time of this writing, none of the extensions and enhancements officially filed as RFC provides anonymity and confidentiality. A way of secure name resolution without these drawbacks is essential for the usability (and therefore popularity) of darknets. Besides speed, users are used to get easy access without having to learn too much about the underlying structures and technologies. Any technique proposed to fill the gap for anonymous name resolution must therefore be compatible with existing infrastructure to allow a seamless experience for the user. Taking advantage of existing protocols and infrastructure provides a well tested and supported foundation that new technologies can rely on without having to bother too much about the basics of transport, scalability and reliability. Reinventing the wheel is not an option for essential services like DNS.

1.1

Related work

In their proposal “Anonymous Resolution of DNS Queries”[7] the authors S. Castillo-Perez and J. Garcia-Alfaro presented a way to anonymize DNS lookups by perturbing real lookups with random DNS queries. This introduces random noise to the channel to lower the chance for successful response manipulation and range intersections, but also comes with great bandwidth consumption.


4

IT-Security

Another approach was shown by Zhao et al. in their publications [8] and [9]. Their proposal is similar to [7] as they introduce a number of queries instead of a single request at a time. Yanbin Lu proposed in [10] another solution for privacy enhanced DNS based on Distributed Hash Tables (DHT). While this approach would offer great anonymity adopting it would result in a complete redesign of the way DNS communication works.

1.2

Outline of this thesis

This thesis is structured as follows: Chapter 2 describes anonymity in general and the need for anonymity in respect of information technologies and political backgrounds. Chapter 3 covers the Domain Name System and its application as well as its role in anonymization. A comparison of different anonymization techniques that can be applied to DNS is presented in chapter 4. In this part the author also introduces aeon - a concept for anonymous name resolution relying on existing DNS infrastructure. Finally, the conclusions are presented.


5

IT-Security

Chapter 2

Anonymity 2.1

Definition of anonymity

Anonymity allows users to access resources or services without revealing their identity. While the user might use a pseudonym in systems that allow full anonymity, there is no way that this nym will be indicative of the users real identity. Anonymity eases peoples willingness to take their freedom of speech and should be considered as a substantial part of the concept of (democratic) voting. It allows individuals to publicly express their opinions without fearing any personal consequences. Anonymity does not protect the actual information that is shared, so this information might still leak evidences about the identity of the author, the recipient or any other individuals involved. In their “Proposal for Terminology”, Andreas Pfitzmann and Marit Köhntopp used the following definition:

“Anonymity is the state of being not identifiable within a set of subjects, the anonymity set. The anonymity set is the set of all possible subjects. With respect to actors, the anonymity set consists of the subjects who might cause an action. With respect to addressees, the anonymity set consists of the subjects who might be addressed. Therefore, a sender may be anonymous only within a set of potential senders, his/her sender anonymity set, which itself may be a subset of all subjects worldwide who may send messages from time to time. The same is true for the recipient, who may be anonymous within a set of potential recipients, which form his/her recipient anonymity set. Both anonymity sets may be disjoint, be the same, or they may overlap. The anonymity sets may vary over time. Anonymity is the stronger, the larger the respective anonymity set is and the more evenly distributed the sending or receiving, respectively, of the subjects within that set is.” [11]


6

IT-Security

As stated in the paper “Towards Measuring Anonymity” by C. D´ıaz et al. most models for anonymity systems use such anonymity sets. These systems incorporate the roles “Senders”, “Recipients” and “Mixes”. Senders are trying to transmit information through a number of participating individuals (also referred to as entities) in order to reach the intended recipient. These participants are willing to relay the information from one entity to another. The collective of entities is referred to as the mix. Before communicating, a subset of entities is randomly selected from the mix and a random vector through the subset ( = sequence of entities) is chosen. The sender now hands over the information to the first entity, which relays it to the second entity without telling the origin of information and so forth. In the end, the receiver should get the information while neither he nor an entity within the subset knows the actual content or the origin. Additionally, every entity may be part of the mix, as well as being a sender or receiver at the same time [12]. The grade of anonymity is strongly tied to the number of participants available within the mix. This explanation is applicable for digital approaches as well as for real world scenarios: People that attend elections and cast their ballots are registered, but their actual vote is hidden within an opaque envelope and put into a box with all the other votes. The entire collection of envelopes within the box represents the mix. The choice made by the participants can now be evaluated, but can not be assigned to an individual person.

2.2

The importance of anonymity today

The ability for people to express their (honest) opinions without fearing consequences by doing so is a fundamential principle of free and secret elections. The participants do not necessarily want to hide their intention to contribute to the election rather than hiding their vote itself. Anonymity guarantees that an individual person feels free to give their support to the politician or party they really want to. Anyhow, some countries that allow their citizens to vote intentionally do not offer this grade of anonymity and even (pre-)select citizens that are eligible for voting in order to control the election results. With the spread of the Internet, anonymity gained importance in the digital world. In 1998 china started the conception of its golden shield project, a national virtual firewall to allow censorship and control of almost all data that traverses the chinese border through the global interconnected networks. Since it began operations in late 2003, information that is concerned to offend chinese citizens, or reflects political or regime critical opinions other than approved by the government, is filtered or manipulated. Rather than just oppressing access to unbiased information the government also logs who is trying to access such sources in order to apply punitive measures on those individuals [13].


7

IT-Security

While this abuses human rights, it is not an easy task for western governments to apply pressure on china because of their economic power. Furthermore, western countries like the United States are exporting their surveillance technologies to china and other regions where online oppression takes place. In a publication covering the golden shield project in 2001, the author stated:

“Old style censorship is being replaced with a massive, ubiquitous architecture of surveillance: the Golden Shield. Ultimately, the aim is to integrate a gigantic online database with an all-encompassing surveillance network – incorporating speech and face recognition, closed-circuit television, smart cards, credit records, and Internet surveillance technologies.” Greg Walton [3]

While being a paradigm for oppression of the freedom of speech, the chinese regime is not at all the only government that started to collect detailed data about their citizens access to information and limits it on their sole discretion. In their report “Internet Enemies” published in March 2011, the international NGO “Reporters sans frontiéres” characterizes China, Burma, Cuba, Iran, North Korea, Saudi Arabia, Syria, Turkmenistan, Uzbekistan and Vietnam as “Internet Enemies” due to surveillance, arbitrary blocking, dubious legal practice and in some cases even imprisonment of so called cyberdissidents [14]. The cuban citizen and activist Yoani Sanchez said about Cubas uplink to the Internet:

“The cable optic fibres are already engraved with the name of their owner and its ideology. This undersea connection seems destined more to control us than link us to the world.” Yoani Sanchez [14]

Not only the countries stated above are gaining more control over the interconnected networks and their citizens. The report reveals worrying details about countries that are regularly spying on their online users: Australia is currently working on a filtering system that is going to be mandatory for all ISPs and can therefore be seen in relation to the chinese Golden Shield. The recent elections in Belarus caused a wave of repression against online information, Bahrain is going to expand their filtering capabilities. South Korea is censoring North Korean content on the web and the United Arab Emirates are intensifying online surveillance and content filtering. Eritrea is trying to detain their citizens from using the Internet at all and monitors users that are allowed to access it due to special permits. In Malaysia, bloggers are imprisoned regularly. In Sri Lanka online journalists are subject to oppression and violence and Thailand


8

IT-Security

officially constrained the freedom of speech while Turkey blocks thousands of websites without true legal hold [14]. Internet users in Australia, Bahrain, Belarus, Egypt, Eritrea, France, Libya, Malaysia, Russia, South Korea, Sri Lanka, Thailand, Tunisia, Turkey, United Arab Emirates and Venezuela are flagged as “Under Surveillance by their governments”. Some of the countries only monitor their users, but a growing number are jumping on the bandwagon of blocking. Although the list of nations under surveillance might seem to be extensive, the dark figure of governments and regimes that are using any form of techniques to censor (digital) information might be much higher [14].

2.2.1

WikiLeaks

The slogan “We open governments” traveled around the world when WikiLeaks came into the world wide spotlight because they released the Iraq War Logs, the Afghan War Diary and the U.S. State Department diplomatic cables. The individuals that are responsible for leaking those informations would have to face massive legal and personal consequences that would most probably have prevented them from publishing them in first place. However, the anonymity guaranteed by WikiLeaks allowed them to release the documents without creating unnecessary risk for themselves and their families. Anonymity therefore is a vital factor to allow the so-called whistle blowing, where individuals inform the general public about incidents that infringe upon their personal- and the general concept of morality [15].

2.2.2

The case “Bradley Manning”

What happens when anonymity fails can be deduced from the case Bradley Manning, who was suspected of leaking the U.S. State department diplomatic cables to WikiLeaks and imprisoned in july 2010. These cables caused diplomatic strains between the united states and nations all around the world. Several politicans postulated that the court should sentence Bradley Manning to death. By the time of this writing, he is still detained in Fort Leavenworth, Kansas, suffering from what the well-established lawyers Bruce Ackerman and Yochai Benkler describe in their petition as “... degrading and inhumane conditions that are illegal and immoral” [16]. The signal for people like Bradley Manning is to never give away sensible information about their government even if they feel the moral urge to do so.


9

IT-Security

2.3

The drawbacks of anonymity

Of course anonymity may unfortunately be subject to abuse. Studying governmental statements, abuse is one of the key arguments against anonymization in general since these techniques may support criminals in breaking the law. This is not fundamentally wrong as anonymity does offer opportunities and may support these individuals. Nevertheless there is a tradeoff in accepting abusive users for supporting users that need to protect their anonymity for good reason. Another disadvantage is the lack of identity information needed for accounting. It is therefore important to deliberate about whether anonymity is needed and reasonable in a given situation or not.

2.4

Summary

Anonymity supports the freedom of speech. It allows whistle blowing, which should not be understood as solely illegal activity but as ethical and moral valve to put the public attention to injustice and entrepreneurial or governmental racketeering. Anonymity - not limited to its digital representation - should be considered as a backbone of freedom and modern civilization. Anonymity is a cornerstone of human rights, free elections and democracy and must be protected from being degraded and dismantled in the name of law enforcement and crime prevention.


10

IT-Security

Chapter 3

Technical background 3.1 3.1.1

Domain Name System A global directory

In the beginning of the Internet Protocol (IP) based interconnected networks, hosts were solely addressed by their respective locator - also known as IP address. This address consisted (and in IPv4 still consists) of 32 bits represented as four blocks of up to three digits separated by dots. Since each of the 4 blocks reflects one octet of the binary representation, every block may take a value from 0 to 255, resulting in 4.294.967.296 unique addresses. With the growing number of participating hosts it got harder to memorize the IP addresses of individual hosts, so the so called “hosts file” was invented. This locally stored human readable text file allowed the user to build a system wide personal table to look up known and regularly used ip addresses by storing them with descriptive hostnames [17]. To distribute this file, users could either retrieve the latest version of the file - the “master hosts file” - periodically from a host at the Stanford Research Institute (SRI) or share and merge their hosts files among each others in order to discover new hosts and services on the Internet [18] [19] [20]. While this solution worked on a small scale, the time and effort of keeping the hosts file up to date and synchronized turned out to be inefficient due to the enourmous number of hosts that joined the networks. Adding new IPs, removing old ones and handling service relocation created a huge logistical problem. In 1983, Paul Mockapetris designed the Domain Name System to replace the hosts file with a hierachical distributed and scaleable directory that translates human readable names to IP addresses and vice versa - a global telephone book for IP addresses [21] [22]. Due to the scalability and robustness of DNS, it became one of the most important services on the


11

IT-Security

Internet today and provides the foundation for e-Mail, spam defense, virtual web hosting, load balancing, IP telephony

1

and many more. It can be considered as a technological backbone

of the world wide web.

3.1.2

Infrastructure Design

The Domain Name System, designed as hierachical distributed directory, logically is organized as a tree of zones that is starting at the root zone, represented by a single dot. Although this dot is always located at the end of each Full Qualified Domain Name (FQDN), its presence is often not known to end users since applications and resolvers take care of adding the dot as suffix to each request automatically. The correct FQDN for “www.blackmesa.at” would therefore read “www.blackmesa.at.” to be syntactically correct. The root zone is under control of the Internet Assigned Numbers Authority (IANA) and at the time of this writing maintained by Verisign, Inc. It is currently served by 246 servers all over the world, organized in 13 clusters named from a.root-servers.net to m.root-servers.net. Each cluster uses a single IPv4 address which is provided by load balancers and anycast routing infrastructure. Each cluster is located at secure and high-bandwidth connected sites [23]. The list of clusters is often delivered with the resolver and known as the “hints file” [? ].It can be seen as pendant to the hosts file used before, providing a way of finding the root zone in order to allow iteration through the whole Domain Name System (DNS) tree. The root zone is authoritative for the delegations of the first zone underneath, also known as Top Level Domain (TLD). According to the root zone database, 324 TLD delegations are announced by the root zone as of July 2011 [24]. This includes country codes as well as generic and sponsored labels. The zone for each country that owns a valid country code delegation within the root zone is maintained by an Internet Corporation for Assigned Names and Numbers (ICANN) accredited domain name registrar. This registrar is in charge of distribute the domain names to interested parties and handling legal disputes, as well as providing the technical infrastructure (authoritative name servers, registration mechanisms, support) for the zone. The organization “NIC.AT” for example is the accredited registrar maintaining the austrian zone “.at”. The correct FQDN at this time reads “at.”. What the name servers of such registrars actually provide are delegations. A customer who buys a second level domain within the registrars scope (e.g. within .at) technically gets his own name servers added to the registrars authoritative servers in form of one or more delegation entries. The name servers provided by the customer are now authoritative for the zone he bought (e.g. blackmesa.at). He may now add records to his zone and also may add delegation entries to name servers to serve another zone below his own. 1

the ENUM extension


12

IT-Security

To retrieve a specific record from the DNS, a request may go all the way up to a root name server which will inform the requesting name server where the TLD of the record in question can be found. The name server will then contact the system he learned about in order to retrieve the address of the name servers(s) in charge of serving the domain of the requested record and so forth. This ensures that - as long as all name servers that are needed to maintain the chain of delegations from the root zone down to the zone containing the actual record are available and configured correctly - every existing record can be retrieved from the DNS infrastructure despite its globally distributed character [22]. To minimize the direct impact to the root name servers they do not handle recursive requests and only reply with authoritative information.

3.1.3

Packet Design

For a better understanding of the protocol itself, figure 3.1 shows the header of a DNS packet, figure 3.2 and 3.3 show the query- and resource record structures transmitted as payload of DNS packets. It is important to understand the structure and packet design in order to fully understand how information is transmitted and how covert channels (see 4.2.4) take advantage of them as a carrier. While all fields in these figures are briefly described in the appendix 6, some are extensively described in this section due to their important role in later chapters.

3.1.3.1

Packet Header

00-15 ID

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 QR

OPCODE

AA TC RD RA

Z

32

TQ

Total Answer RRs

64

TA

Total Additional RRs

96

Questions[] :::

...

Answer RRs[] :::

...

Authority RRs[] :::

...

Additional RRs[] :::

AD CD

RCODE

Figure 3.1: DNS Packet: Header and Payload

The top row refers to the (number of) bits used for representation while the first column


13

IT-Security

indicates the starting bit of each row. Bits start with zero (0). Each row is therefore 32 bits wide. ID: Identification 16 bits Used to match replies to the appropriate request since DNS over User Datagram Protocol (UDP) is stateless. An attacker predicting this value would be able to spoof DNS replies by simply sending them before the real name server does. This field is randomly generated by the client. TC: TrunCation 1 bit Flag field. Indicates if only the first 512 octets of the reply was returned and the rest of the information is truncated due to the maximum payload limit. Depending on its configuration, the client will either give up or reissue the request in TCP. Although requests can usually rely on UDP or TCP, UDP is proposed as the standard way of sending queries (when possible). RD: Recursion Desired 1 bit Flag field. The server is asked by the client to recursively resolve the request on behalve of the client if the server is not authoritative for the requested information or the data is not cached yet. RA: Recursion Available 1 bit Flag field. Indicates if the server is able and willing to recursively resolve requested record(s). Most DNS servers operated by access providers allow recursive resolution. The root servers that form the backbone of DNS usually do not provide this functionality in order to keep their load down and force customers to use the name servers provided by their access providers. Z: 1 bit Reserved. Must be 0 in queries as well as in responses. Was originally 3 bits in size as defined by [22] but narrowed down to 1 bit by DNSSEC.


14

IT-Security

3.1.3.2

Packet Payload: Query Structure

00 - 15 00

AES()

16 - 31

Query Name :::

32

Type

Class

Figure 3.2: DNS Packet: Query Structure

Query Name: Variable Length A FQDN represented as a sequence of dot-separated labels. Each may use up to 64 octets in size, the full sequence must not exceed 255 octets (including the dots between the labels as well as the dot representing the root zone). Type: 16 bits The requested resource record type. The basic set (A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO, MX, TXT) was described in RFC 1035[22]. If set to OPT, the protocol extension EDNS0[25] will be used. Class: 16 bits Usually set to 1 referring to IN (the INTERNET class), but may also be CH (the CHAOS class) or HS (the HESIOD class). While the latter class was planned as a pendant to Sun’s Network Information Service (NIS) and is practically unused, CH is still supported by various DNS servers to get technical information as - for example - their software version number.

3.1.3.3

Packet Payload: Resource Record Structure

00 - 15 00 32

AES() Resource Record Name :::

Type

64 96

16 - 31

Class TTL

RDATA Length

RDATA :::

Figure 3.3: DNS Packet: RR Structure

Resource Record Name: Variable Length Basically copied from the Query Name field of the query structure.


15

IT-Security

Type: 16 bits The requested resource record type. The basic set (A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO, MX, TXT) was described in RFC 1035[22]. If set to OPT, the protocol extension EDNS0[25] will be used. Class: 16 bits Usually set to 1 referring to IN (the INTERNET class), but may also be CH (the CHAOS class) or HS (the HESIOD class). While the latter class was planned as a pendant to Sun’s NIS and is practically unused, CH is still supported by various DNS servers to get technical information as - for example - their software version number. TTL: 32 bits Time To Life (seconds). How long shall the local resolver or an intermediate server cache the information within this resource record. After the given number of seconds a client or intermediate name server removes the data from its cache and requests it again on demand.

3.1.4

Workflow of the DNS protocol

A client (eg. Webbrowser) that tries to retrieve a website addressed by a DNS record, will ask the DNS resolver built into the local operating system to translate the name provided to an IP address before it is able to establish the connection. The resolver will - depending on its implementation - try to retrieve this information from a local hosts file and from its cache. If both do not hold the data or the cached information is outdated, it will forward the request to the primary DNS server configured by the IP stack of the system which is, in most cases, the DNS server of the ISP. For this communication, the UDP port 53 is used. If the size of the answer and its header information exceeds the maximum payload of an UDP packet (512 Bytes), Transport Control Protocol (TCP) on port 53 can be used instead [22]. Arrived at the DNS server, there are four possible ways how the request may be processed:

Authoritative Answer: If the DNS server itself can answer the question because he is hosting the zone in question, he will be able to form an authoritative answer for the requested information and send it back to the client. This might imply that the name server owns a valid delegation entry within the zone above, but the server itself decides whether to mark the answer to be authoritative or not. The authenticity of the apparently authoritative answer is not guaranteed just because the respective flag is set. Rogue or misconfigured name servers may deliver wrong information. Using signed protocol extensions, for example Domain Name System Security Extensions (DNSSEC), adds authenticity to these answers. Non-Authoritative Cached Answer:


16

IT-Security

The server might hold the requested information in its cache. If this information is not outdated due to the TTL of this record, he will use the cached information for the reply. Non-Authoritative Recursive Answer: Most of the time a non-authoritative name server contacted by the resolver will not be able to fulfill the request on its own. In recursive mode, the name server will retrieve the information by contacting further name servers to obtain the resource record. As soon as the name server managed to retrieve the resource record, it will send it to the client. Technically, such a request could be recursed all the way up to a root name server. Non-Authoritative Iterative Answer: In iterative mode, the name server will provide the resolver with a set of name servers that will - most probably - be authorized to fulfill the request or at least know further servers to ask. The client itself has to contact further name servers in order to resolve the record in question.

Either way of domain name resolution - authoritative, recursive or iterative - will success to deliver the requested RR as long as the chain of name servers involved is configured correctly, reachable, the zone is officially delegated and the resource records exist. The distributed approach in conjunction with its strictly hierachical character provides a robust and scaleable way to resolve names and IP addresses since its invention.

3.1.5

DNS and anonymity

Since DNS became a fundamential part of the Internet, the DNS resolver is integrated into all major operating systems nowadays. Back in the days when the DNS protocol was developed, confidentiality and privacy did not receive the same amount of attention they do today. In the beginning of the Internet, the number of participants was rather small and manageable - most of the users were only able to get access on their universities network. The protocol evolved over time. As the time of this writing, 137 Request for Comments (RFC) articles about DNS were published, proposing enhancements and extensions to the service since it was proposed in 1983. While some of them added capabilities for authenticating DNS messages, none of them explicitly covers anonymity and encryption of the payload transported2 . Anonymization networks can tunnel DNS requests too, but not all of them may support transport over UDP. Further it may increase anonymity to use separated channels for resolving and communicating.

2

DNSCurve, the protocol for encrypted name resolution proposed by D.J. Bernstein, is no official RFC yet.


17

IT-Security

3.2

Darknets

Darknets are virtual networks implementing their own protocol and application layer atop of existing network infrastructure - a form of network piggyback. According to P. Biddle et al. the term “Darknet” refers to distribution networks that emerge from the injection of digital or analogue material that deserves protection (a.k.a. intellectual property) into high bandwidth channels where other participants will copy and redistribute them [4]. They are often formed by so called peer to peer networks. On the following chapters the term does not focus on the possibility to redistribute intellectual property but on communication over covert channels or cascades that allow to hide the origin and/or destination of information as it traverses the virtual network. A darknet should not be perceived as medium for piracy but as platform for anonymous and uncensored information exchange. This section describes some common virtual networks and their individual approaches.

3.2.1

Tor

Tor is an anonymization network designed by the U.S. Naval Research Laboratory to protect government communication. Nowadays it protects a variety of internet users from traffic analysis and losing their privacy when consuming information and communicating over the interconnected network. It uses TCP for transport and onion routing algorithms to build a so called mix-cascade [26] where a temporary virtual circuit is established that consists of randomly chosen nodes3 from the mix. The information is routed through this virtual circuit for a limited period of time until a new circuit is built. Tor supports two operational modes. Most people use it as some sort of web- or serviceproxy where the information requested and retrieved is encrypted and routed through a number of at minimum three participating nodes. This cascade allows the software to cover the tracks of the person that initially transmitted data since every single connection between two nodes adds another layer of encryption. Due to the cascade and its encryption, none of the nodes actually knows the complete way the data takes through the network. To allow legacy communication with non-Tor enabled systems (the “plain old Internet”) so called exit-nodes route the data out of the mix to the intended receiver and deliver the responses - back through the cascade - to the node that originated the request in first place. Neither the originator nor the destination service is able to determine the communication partner on the information provided by the OSI layers 2 - 4. Nevertheless, information may 3

the procedure does not use true randomness as Tor tries to choose nodes in respect to their utilization and capacity to build low latency circuits. Additionally the last node in each circuit has to be an exit-node.


18

IT-Security

be leaked due to the Domain Name System (see section 3.1.5), which may resolve the initial request without using Tor to anonymize the connection to the name server [27]. The second mode of operation is called “Hidden Service” and eliminates legacy communication with the plain Internet and therefore the need for exit-nodes. The resulting darknet ensures that data transmitted into the network will never leave the mix. This implies that only services that are participating in such a network can be accessed and users inside the darknet are perfectly anonymous in respect to the information available on OSI layers 2 - 4. The services are addressed by an 16 character name derived from an unique hidden service descriptor4 referred to as “onion key”. Connections are requested by clients at introduction points that allow client and server to build the new connection at a random rendezvous point [28]. Since an onion key is the base-32 encoded representation of an 80 bit part taken from the 160 bit SHA-1 hash of the hidden service public key, it is not really easy to remember. Example: The onion key to address “The Hidden Wiki” - a former well known but meanwhile offline MediaWiki instance provided as hidden service - was 6sxoyfb3h2nvok2d.onion. To deal with this issue, as well as to eliminate the need for proxying applications, a software called onioncat creates a transparent IPv6 layer on top of hidden services. An extensive information about onioncat and the technique of mapping onion keys to IPv6 addresses is available in [29]. Of course IPv6 addresses are also hard to remember, but this limitation can now be compensated by using DNS with all its advantages and all its major drawbacks in respect to anonymity.

3.2.2

I2P

A similar approach to creating a darknet is used by the anonymization network I2P. The concept of layered encryption and the usage of tunnels as pendant to circuits is basically an extended onion routing technique, but I2P is designed from scratch to act as darknet without trying to let the users access the plain Internet. Further, I2P is able to use TCP as well as the unreliable UDP for transport. As a result, I2P sessions are set up faster than Tors hidden service sessions and feature lower latencies. I2P tunnels are established unidirectional, so two tunnels are needed for bidirectional connections and requests take other paths through the mix network than replies do [30]. A fundamental difference to other anonymization networks is that applications may have I2P support implemented in order to work inside the darknet. Other applications may use the Socks interface. I2P also supports the use of base-32 identifiers to address services within the network. These “destination keys” are 52 bytes long and therefore much shorter than their 516 bytes base-64 represented equivalents. Nevertheless, both of them are not easy to remember. The former mentioned software onioncat - in I2P mode also called “garlicat” - provides a 4

to be exact, the name is derived from the public key which is part of the descriptor.


19

IT-Security

transparent IPv6 layer and so opens the doors for using DNS [29].

3.2.3

Freenet

Created by Ian Clarke, freenet aims to provide a platform for censorship-resistant information exchange. The decentralized network randomly routes requests and responses through an cascade of neighbour relationships between its nodes. The content is stored in blocks which are stored all over the virtual network. Since the blocks are encrypted, the owner of a participating host is not able to determinate the actual content he is hosting at a given time which provides plausible deniability for node operators in respect to law enforcement. While information traverses the network, the nodes in between are constantly caching the blocks they forward, which increases the availability of the content stored within freenet. Due to this caching, more popular blocks profit from better speed since more nodes are able to serve them at the same time. Each node can build neighbour relationships to any other participant which results in an mesh network topology. Content is addressed using a set of keys to ensure that any blocks transmitted were not tampered and allow users to create nyms that can be used to sign and verify content they initially injected into the darknet without revealing their true identity [31]. Freenet does not allow access to content outside of the mesh network since it is not a proxy solution. Although extensions like freesite allow surfing web content inside freenet, it was primarily designed for file transfer and is not suitable for realtime / dialogue based communication like e.g. layer 7 protocols of other applications than freenet would demand. Hence, no addressing like DNS is needed here.

3.2.4

anoNet

AnoNet uses similar approaches like Tor and onioncat do, but it does not feature any encryption. By design, it is not necessary to add encryption since anoNet builds a transport layer network that is able to host virtual private networks like e.g. openVPN or IPsec implementations for added confidentiality [32]. Anonymity is not created through sending packets through a mix cascade across the network but through chaos routing [33]. AnoNet hosts simply use the network range 1.0.0.0/8 on IPv4, as well as de00::/8 on IPv6 for connections, which was reserved by IANA when the network was designed5 . To allow communication, a routing mechanism is needed that does not take advantage of the official world-wide routing infrastructure. This is achieved by using Border Gateway Protocol (BGP) and providing a registration platform where participants can claim their BGP Autonomous System Number (ASN)s without providing their real identities, using a 5

meanwhile, 1.0.0.0/8 has been allocated to Asia-Pacific Network Information Centre (APNIC)


20

IT-Security

pseudonym instead. Communication is performed over “virtual cables” created by openVPN connections on the real Internet. Network nodes only know the IP address of their immediate peers. Peering is preferred with nodes across countries to take advantage of the noncooperation of network service providers when it comes to international investigations [34]. The major advantage of anoNet is that every application that was designed to use the Internet will be able to use anoNet without modifications. The whole set of IP-ready soft- and hardware will be able to participate anoNet out of the box. The domain name system is an integral part of the anoNet user experience because of the need to translate names to IP addresses and vice versa. Unfortunately - as this is true for Tor and I2P - DNS may be one of the weak links in terms of anonymity for anoNet.

3.3

Summary

Mnemonic addressing is not an easy task within darknets due to their individual and proprietary methods of generating their unique identifiers. Even though there are techniques that allow the usage of DNS to map identifiers to human readable names, it is not that simple to take advantage of its features due to the resulting risk of information leaks. To resolve this issue, a reliable and easy to use method of anonymizing DNS must be found. Otherwise, the drawbacks of using the global name resolution directory far outnumber the advantages and may obsolete the use of anonymization networks.


21

IT-Security

Chapter 4

Anonymization of DNS 4.1

The hosts file

Most operating systems feature some kind of hosts file for compatibility reasons. On Unix and Unix derivates it is usually located at /etc/hosts. Windows uses the registry to determinate the location of the file. By default the registry key points to C:\%SYSTEMROOT%\System32\ Drivers\etc\hosts. With the invention of DNS, the hosts file became less important and is now primarily used to map the loopback address (127.0.0.1) to the hostname localhost as well as to allow the user to temporary assign hostnames to IP address on a local system without using DNS. But the hosts file is not necessarily dead. Due to the increasing amount of advertisments on the web, some ad blocking solutions use it to redirect resource requests (e.g. image downloads) that were pointing to well known advertisement servers directly to the loopback address of the local system, which won’t be able to satisfy the request. Doing this prevents unwanted resources like images, flash files or even tracking scripts from being loaded and displayed. On a small scale, this solution may also be used for anonymous domain name resolution without actually using the DNS infrastructure itself. To achieve this, a central database must be provided that allows names to be registered through an anonymous web interface, as well as provides a method for one-way synchronization of the database with the local hosts file of a participating client. Both of this access methods should be limited to be used over anonymity networks or - at best - only within darknets as provided by Tors hidden services and I2P. Since entries may need to be updated by the owners of the system, a random one-time key for each registered name will be used to identify the holder of the name. This allows the users to maintain their own entries while not being tracked or identified by user accounts. In order to reduce the load of the synchronization, a serial number similar to the serial number


22

IT-Security

of DNS zones may be used. It will indicate what entries have changed since the last run and must be updated on the local hosts file. To keep the hosts file free for other purposes, the entries must be tagged (by adding parseable comments) in order to seperate them from other entries (e.g. by AdBlocking Tools). Given that the operating system is set up to let the resolver use the hosts file before sending the request to the DNS server(s), the (A- and AAAA-) lookups for all FQDNs indexed within the local database are now anonymous since they do not leave the host. The setup is very trivial and may be compatible with most modern operating systems, but there are clear drawbacks to this solution. One of the reasons for the Domain Name System being developed was the poor scalability of synchronized hosts files. The number of entries currently needed to use DNS for addressing hosts within darknets may be feasible to be stored this way, but with the growing number of users the hosts file will not be able to hold all the entries at once. Another issue is the so called Zonewalking, where an attacker may be able to retrieve a list of all hosts within a given namespace. Having a single file containing all zone information, a major security issue will arise1 . The risks associated with this solution can be compared with running authoritative name servers that allow the usage of Asynchronous Xfer Full Ranges (AXFR) to everyone. While the purpose of A and AAAA records may be used, all other records are not covered by the hosts file since it does not feature resource record types as MX, PTR, TXT and so forth. All these concerns and issues lead to the conclusion: The hosts file does not scale, it may work in small environments with a limited number of features but won’t be able to provide anonymous resolution in familiar DNS manner.

4.2 4.2.1

Possible Tunneling techniques SOCKS

When a user needs to tunnel DNS queries, SOCKS comes to mind. Tor for example provides tor-resolve - a script that connects to the SOCKS 4a proxy provided by Tor (9050/tcp) and performs the resolve command. The correct version of SOCKS is important: For performance reasons, most applications supporting v5 try to resolve hostnames on their own before handing the request to the service behind. Version 4 of the proxy service is not even capable of name resolution, therefore the only version to be considered is v4a. Although SOCKS is able to resolve hostnames, this requires support within the client application. In respect to usability, the configuration of applications that feature such support is another issue since all these 1

even though the security gain relies on missing knowledge and can therefore be referred to as security by obscurity.


23

IT-Security

applications would have to be configured manually [35]. These applications may be subject to implementation flaws that could leak queries, e.g. by not forwarding them to the proxy despite of their configuration. Furthermore an anonymization service must be installed that provides an interface supporting the correct protocol version. Simply using a proxy for DNS without using anonymization techniques behind does not add any confidentiality or anonymity at all. The proxy service might leak information as well and therefore can not be trusted. All that said, SOCKS can’t be considered as a safe, robust and available solution to tunnel DNS queries system-wide. Speaking of Tor, tunneling DNS communication through an onion routing infrastructure is not a solution since it is only intended to hide the origin the queries come from but in the end uses unencrypted communication when talking to a name server on the last hop.

4.2.2

VPN

Using a VPN (e.g. openVPN) configured to route all traffic into the tunnel appears to be a solution since all connections - DNS lookups included - will be redirected to the remote VPN Gateway. Unfortunately this does not necessarily increases anonymity. The remote VPN gateway knows the origin of the tunnel, is able to decode the DNS traffic and may leak this information without the client noticing this. Since there is no gain in anonymity and the lack of control over the clients identity, using VPNs is not a trustworthy solution too.

4.2.3

Redirection via packet filters

Packet filters may be used to redirect outbound traffic to port 53 directly to a proxy service that solely uses name servers within a darknet or through a mix-network. The advantage of such redirections is that lookups can not leave the host uncontrolled and therefore are not subject to unintentional leaking. Further the implementation is quite simple since due to the system-wide character of packet filter redirections there is no need to configure or modify client applications. Even client applications that do not use the operating systems resolver libaries are covered and secured. All traffic can be passed to a service listening on the loopback interface which handles the anonymization part. The ruleset of such packet filtering solutions must be tied to the state of the local darknet- or mix-network client. Otherwise, DNS would not be available as soon as the user decides to disable the anonymization layer. Packet filters are available on BSD (pf), Linux (iptables), OS X (ipfw) and even Windows (wipfw).


24

IT-Security

4.2.4

Covert Channels

Another way to tunnel DNS queries are covert channels, sometimes referred to as “protocol piggyback”. This technique converts data to match a certain protocol that is allowed to pass firewalls and other policy enforcement systems without them noticing. While this theoretically abuses the protocol that acts as unintended carrier, it does not violate its specification (e.g. by being strictly implemented in respect to the according RFC) and therefore is very hard to detect. For this technique to work, the receiving peer must be aware of the modification and able to decode the incoming data in order to convert it back to the original information [36]. Many protocols - e.g. Hyper Text Transfer Protocol (HTTP) or Internet Message Access Protocol (IMAP) - are suitable to be used as carrier for covert channels, but most of them may be subject to modifications on their way through the network - DNS though is not. Connections to certain services that seem to be eligible to apply such techniques may be blocked by firewalls or modified on their way through proxy servers and other application level gateways. DNS itself turns out to be a very robust carrier for covert channels since it is available on most networks and even will pass through firewalls and deep inspection mechanisms. Even DNS servers located inside a companies network allow covert channels to be built upon their service while they are literally just doing their job. Besides all robustness DNS tunneling comes with severe drawbacks concerning performance and efficiency [37]. Tom van Leijenhorst, Kwan-Wu Chin and Darryn Lowe investigated on the viability and performance of DNS based covert channels in 2008. The result of their analysis revealed that clients using DNS tunneling may reach up to 110 KB/s in throughput, but may increase the overhead of the transported protocol up to 2000 percent compared to its intended way of communication without using the tunneling technique [38]. Also DNS tunneling is very limited due to the protocol specification, particularly in regard to upstream communication (requests) sent by the client using DNS queries. Unlike the DNS response that will use significantly longer TXT records, request-embedded covert channels may have to get along with very limited space. Assuming a fully exhausted top level domain label, as well as a fully exhausted 2nd level domain label and the dots needed for dividing the remaining labels into segments of 63 octets, only 125 octets (= bytes) remain for the covert channel. At the time of this writing, the longest available top level domain label currently in delegation2 by the IANA is “museum”, consuming 6 octets and leaving the minimum capacity for requestembedded tunneling at 181 octets [24]. Since the ICANN decided in 2008 to relax the terms and conditions for filing new top level domain applications, longer top level domain labels might show up in (near) future [39]. Under ideal circumstances and in respect to the 2-lettersminimum policy of all available TLD registries, the maximum capacity to embed information 2

except from IANA Internationalized Domain Name (IDN) test TLDs - they consume up to 18 characters.


25

IT-Security

into DNS requests sums up to 245 octets. When building a covert channel atop of DNS, a number of headers may be used for signalling or transmission of additional data. Even header fields that happen to be “reserved” for future use as described by the according RFCs may be suitable to transmit signals. Nevertheless the covert channel should stick to the RFCs and to common practice as tight as possible to avoid attracting attention through suspicious behaviour. Deep inspection firewalls and intrusion detection systems may notice that a reserved flag field usually set to “0” suddenly contains uncommon information. Another tripwire may be recursing name servers that may not read fields that are reserved (usually set to 0) or contain the same information all the time as the resource record class3 From their point of view they can for example safely ignore reserved headers and set them to default when creating a recursive request since whatever information would be in there is not important to the RFC compliant protocol at all. Hence, additional information may also be lost while being relayed due to server side performance optimizations and mess up the covert channel. A well designed covert channel always tries to stay stealth and avoids conflicting with common implementations. This prevents the tunneling technique from being noticed and may also render filtering methods against protocol piggyback solutions ineffective. This narrows the bandwith available within the respective carrier protocol, but for anonymization of DNS queries, bandwidth is not that important anyway as only small amounts of data have to be transmitted.

4.3

Anonymous Name Servers

Using a so called “Anonymous Name Server” does not necessarily mean that using this name server provides any anonymity to the lookup process at all. The term refers to the anonymity of the person or company that is providing the data which is served by the name server. Web service resellers do not want their customers to know where they get their services from to avoid that the customer might try to get a cheaper contract directly from the company the reseller buys the service from. Since the customer might get this information from the publicly accessible WHOIS databases, a name server that does not show any specific information about the datacenter or company is used. This allows the reseller to use name servers that are operated by their upstream provider without revealing him. There is no advantage for users that want to perform anonymous domain name lookups since the term “Anonymous Name Server” is misleading. 3

usually the class is set to IN which is referred to as the “Internet Class”. All other classes known at this time are not commonly used or even supported throughout all DNS server implementations.


26

IT-Security

4.4

aeon: Anonymity Encapsulation Over Nameservice

Compatibility with the existing name service is important for anonymity solutions. It should not be necessary to exchange major parts of the technology and infrastructure, particularly because the robustness of DNS is proven and tested over years. To transport DNS over an adequate type of covert channel - for practical reasons over DNS itself as described in section 4.2 - is the main idea behind this concept. Aeon aims to provide anonymous DNS lookups by encrypting requests and responses. All communication is transported using DNS tunneling through an unauthoritative name server to the delegated server capable of handling such requests. The request and reply formats are - based on using covert channel techniques - full DNS compliant and should not attract attention based on protocol consistency and other protocol related sanity checks. Some optional optimizations like the “retry on truncation” feature might partially change the behaviour of the request as a whole but they do not modify the behaviour and structure of each individual request. Changes to header fields like using the remaining reserved 1 bit wide Z header as needed for the mentioned truncation feature are also considered to be optional and may be omitted in order to avoid attracting attention of very strict intrusion detection systems. Very important for the overal security is to avoid messing up existing security mechanisms by modifying headers like the ID field. Security measures included by various RFCs should be studied carefully before changes to headers and payload are introduced. Aeon aims to keep the nature of headers it changes as it does for payload. The protocol overlay is able to verify information sent or received and additionaly is able to transport EDNS0 [25] based packets which are necessary for DNSSEC. Due to the usage of encryption and relaying techniques neither the server knows who requested the information, nor the relaying unauthoritative name server knows what kind of information (which resource record) was requested. Of course this also applies to the information returned by the service. While DNS tunneling is known to be an inefficient and slow method of communication, it works in virtually all setups that are capable to handle conventional domain name lookups. Although it tries to avoid time- and bandwith consuming operations, the additional time added to a lookup may be improved in later versions of the concept. It may be used as standalone DNS client or built into applications to simply rely on the resolver shipped with the operating system. The standalone variant uses redirection through the systems packet filter as described in 4.2.3. To do that, is gets either notified by the anonymizer or scans for established connections to an anonymous networks. As soon as it detected that the anonymizer is up and running, it reconfigures the packet filter. All outbound connections to port 53 will be redirected to the aeon client which now communicates directly


27

IT-Security

with the resolver. Since all applications that relate on the built-in resolver will continue to do so, no modifications to client applications are necessary. When the anonymizer is disabled by the user or its connection to the mix is disrupted, the firewall rules used for the redirection must be disabled to prevent the user from being unable to use plain DNS. The user needs to be informed of the fact that DNS lookups are now visible to eavesdroppers and the name servers again. The alternative to firewall based redirections is the creation of aeon-enabled applications, for example an extension for the open source webbrowser Firefox. Instead of sending the lookup to the resolver immedeately, the extension - acting transparently for the user - will transform it to a modified request that is passed to the resolver afterwards. In this mode the plugin also has to take care of the correct interpretation of the response. This allows some sort of temporary use that is limited to a set of applications and does not require modifications to the operating system and its services. Nevertheless, this mode won’t guarantee that the request will be sent with the Recursion Desired flag set. By design, only a recursive request is able to protect the anonymity of the resolving client to the authoritative server. Further, the huge number of applications to be adapted or rewritten causes this way of implementation to be inconvenient, expensive and time-consuming. Firewalling mechanisms are available to almost every platform that supports networking and therefore predestined to be used for rerouting DNS packets through the aeon resolver. The workflow proposed in section 4.4.1 should be considered as conceptional draft since it was not implemented and tested on a grand scale yet. Performance considerations might arise from using asymmetric crypto systems. Note that aeon is not the only proposal that uses asymmetric cryptography with DNS. DNSSEC, which has been already implemented into major zones and the root zone as of this writing, was developed to provide authenticity to resource records. DNSCurve, a mechanism providing confidentiality proposed by Dan Bernstein, uses an elliptic curve based asymmetric crypto system to accomplish its tasks [40]. The proposed algorithms used by aeon do not necessarily provide the best performance and therefore might be subject to change while implementing a proof of concept. As systems still increase their performance according to Moore’s law as of this writing and will - according to Intel Senior Vice President Pat Gelsinger - continue to do so at least until 2029 [41], the latency introduced by cryptographic operations will decrease. Further, some of those cryptographic tasks may be outsourced to the Graphics Processing Unit (GPU) as this is already possible for protocols like Secure Sockets Layer (SSL) [42].


28

IT-Security

4.4.1

Workflow of aeon

The following workflow - as illustrated in fig. 4.1 - describes how aeon will work when used as standalone DNS client. Note that transparent arrows illustrate requests while opaque arrows refer to replies. Further, single headed arrows show original information while double headed arrows refer to forwarded information flows. First, the aeon resolver will be spawned by a local client in order to resolve retrieve informations from within the Domain Name System. Instead of contacting the name server and handing over the hostname in question, it first prepares the aeon request stanza (the proposed structure of this stanza is explained in section 4.4.2).

Generate Response Stanza

Resolver wakes up Generate SESSKEY

Intercept lookup

Retrieve Public Key

Generate Request Stanza

Public DNS Server B Public DNS Server A

Retrieve information via DNS or from cache Decode Request Stanza

aeon Client

aeon Server

Figure 4.1: aeon workflow

Both informations - the intercepted lookup and SESSKEY - are encrypted through Rivest Shamir Adleman (RSA) using the public key of the aeon capable name server and converted to base324 afterwards. Assuming that the aeon-capable name server is authoritative for the zone foo.bar, the name of this zone is then appended to the encrypted and encoded request. The resulting request stanza (e.g. JFGEYVKTKRJECVCJJ5HCAT2OJRMQ.foo.bar) must not be longer than 255 characters to preserve RFC compliance. Also a dot has to be inserted into the hostname after every 63rd character sent to the conventional DNS server configured for the system [22]. This might be a server provided by the internet provider or company. Very important is that the request must be sent recursive so that this conventional name server will relay the request instead of sending back the set of authoritative name servers for foo.bar. This is achieved by setting the RD flag within the DNS message header. Also the type of resource record that is requested has to be TXT since we do not expect the answer to be unencrypted. The intermediate name server will now contact the name server authoritative for the zone foo.bar in order to get the resource record in question. The aeon name server will decode 4

Base64 would dramatically increase efficiency, but can not be used since DNS is case-insensitive. Uppercase characters may be converted to lowercase while passing intermediate name servers which causes loss of information.


29

IT-Security

the base32 part and decrypts it using the private key. After the original request information is retrieved from the stanza, the name server will try to get this information either from its own cache or by resolving the resource records on behalf of the client. The cascade of servers used for an lookup over aeon is shown in fig. 4.2. It illustrates the name servers that are a always involved (NS[x],NS[y] as well as the set of name servers that may or may not be part of the cascade due to the recursion (a,b,c,d,e,f). As soon as the name server obtained all informations necessary to answer the stanza, it will craft the response. The payload is encrypted using a symmetric algorithm and the session key extracted from the request stanza. Note that due to the public key encrypted request only the originating client and the aeon name server are aware of the session key.

CLIENT [aeon client]

a b

c

NS[x] aeon server

encrypted communication

d e

f

NS[y] authoritative server

unencrypted communication

Figure 4.2: aeon communication cascade

A symmetric system is used for efficiency reasons as it is much more performant than its asymmetric pendant [43]. This does not affect confidentiality since the key exchange was sufficiently secured. Now the aeon name server has to resolve the request on behalf of the client. It should use a name server chosen from a preconfigured pool of servers and may also use iterative requests if necessary. Of course, this time the advantages of caching may be used in order to reduce the time added for the additional lookup. The resulting answer - along with another checksum - is symmetrically encrypted using the session key, encoded5 and sent back to the intermediate name server which will pass it on to the client. The answer must not exceed 65535 bytes since this is the maximum length defined in RFC 1035[22]. However, this limitation may be doubled when using optimizations like “retry on truncation” as described at 4.4. The client decodes and decrypts the answer using the session key he created in first place and verifies its integrity using the checksum included. The answer is then forwarded to the application that requested this information. To do this, the answer must be formed by using the original request (containing the 2 bytes identification header chosen by the resolver) and adding the extracted payload from the response stanza to it. For the client, the answer will not be distinguishable from any other answer. How the client gets in possession of the public key of the aeon name server which he uses for asymmetric encryption is not defined yet. The user could either configure it manually, as well 5

using either base32 or base64


30

IT-Security

as it could be distributed via plain DNS by storing the public key into a TXT resource record. Letting the user decide about what key is used would lower the convenience, but increase trust since integrated keys could be forged through attacks to the DNS protocol (cache poisoning, untrustworthy intermediates, etc.). A secure and convenient way to bootstrap such informations is to be designed with care as the whole concept of security is based on the trustworthiness of the name servers public key - any flaws would render the system vulnerable to Man In The Middle (MITM) and spoofing attacks.


31

IT-Security

4.4.2

Communication format

4.4.2.1

Request Stanza

The request stanza is used to encapsulate the original request payload to be transmitted safely to an aeon enabled name server. The proposed structure of the request stanza is shown in fig. 4.3, but may be subject to changes in further versions. It consists of three information fields that are encrypted using an asymmetric cryptosystem like RSA and encoded to base32. In the end, the appendix is added which is used to address the aeon enabled name server within the legacy DNS infrastructure / protocol. It simply contains the zone the aeon-capable name server is known to be authoritative for.

00-15 ID

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 QR

OPCODE

AA TC RD RA

Z

32

TQ

Total Answer RRs

64

TA


AD CD

RCODE

96 ...

REQUEST

SESSKEY

CHKSUM

RSA()

BASE32()

APPENDIX

...

Figure 4.3: Structure of an Aeon Request Stanza

The following information fields are considered to be the actual payload: REQUEST: The original request information, consisting of the name of the resource record in question, as well as the resource record type (SOA,A,AAAA,...). Note that, although the original request might be asking for an AAAA record, the final aeon request stanza will ask for a TXT record. SESSKEY: The session key, randomized for each request stanza. Used for the symmetric encryption / decryption of the response. Additionally a randomized content avoids (but does not fully eliminates the chance) that several requests of the same resource record would create the same request payload. While this has negative impact on the caching features of DNS (since two equal requests won’t result in the same payload) and therefore on the overal performance, it improves confidentiality of repetitive lookups.


32

IT-Security

CHKSUM: To allow the aeon name server to verify the successful decryption of the request, a checksum is generated from the REQUEST and SESSKEY fields. It may be swapped out to the header see 4.4.4 for details.

4.4.2.2

Response Stanza

The response stanza is used to transport the encrypted answer back to the resolver. The proposed structure of the response stanza is shown in fig. 4.4, but may be subject to changes in further versions. It contains two information fields that are encrypted using a symmetric cryptosystem like Advanced Encryption Standard (AES) and encoded to base64 afterwards. The response stanza is always formatted as TXT record.

00-15

22 23 24 25 26 27 28 29 30 31 16 17 18 19 20 21 AES()

00

ID

QR

OPCODE

32

TQ

Total Answer RRs

64

TA


96

AA TC RD RA

Z

AD CD

RCODE

aeon Request Stanza

... ... ...

REPLY

CHKSUM

AES()

BASE64()

Figure 4.4: Structure of an Aeon Response Stanza

The following information fields are considered to be the actual payload: REPLY: The reply that was gathered by an additional lookup performed by the aeon name server. All collected information (including failure codes provided in the header) is included. CHKSUM: To allow the aeon resolver to verify the successful decryption of the reply, a checksum is generated from the REPLY field.


33

IT-Security

4.4.3

Retry On Truncation

Clients usually use UDP in order to resolve domain names. If the answer created by the name server would exceed the maximum response size permitted on an UDP based transmission channel, the client may reissue the request using a TCP based transmission channel as already used for AXFR also known as zone transfers [22]. Aeon could use the truncation flag to double the capacity of UDP based replies. When an aeon enabled name server formulates an answer that would not fit into an UDP based reply packet, it truncates the message and sets the TRUNCATED flag in compliance to [22] and writes the rest of the truncated reply to a temporary buffer. The aeon client is made aware of the fact that a part of the answer is missing and writes the truncated message into an internal reassembly buffer. Then the client reformulates the request with the Z bit (reserved as of the protocol specification) set to 1. Noticing the Z bit, it replies with the remaining part of the former truncated message from its buffer, still with the Z bit set to 1. Receiving the answer the client reassembles the two parts of the reply and continues the workflow.

4.4.4

Checksum based Identification header

The identification header of DNS messages as described in 6 is needed to match replies to their respective requests. This field is randomly generated by the client for each request and may also be (mis-)used to transmit 16 bits of information. Aeon could use these 16 bits to store the aeon request CHECKSUM outside of the stanza in order to save precious label space. With this CHECKSUM aeon would still be able verify the successful decryption of the request while preserving randomness due to the SESSKEY which is subject to change for every formulated packet and will have impact on the CHECKSUM.

4.5

Design considerations regarding covert channels

There are still many things left to be improved within the aeon protocol, especially the design of the covert channel. The maximum length of an original request that can be handled is effectively reduced by the amount of overhead added by encryption and conversion applied to the original FQDN. Hence, the proposed design will not be able to resolve FQDNs that are 255 octets in size, as allowed by RFC 1035[22]. To avoid this, a way of sending a number of related lookups may be designed so that the covert channel maintains full RFC compliance.


34

IT-Security

4.6

Summary

There are several ways to tunnel DNS, as well as different techniques to hide the payload from being analyzed on its way to the name server. Since it minimizes configuration efforts and mitigates information leaks due to bundled resolvers and implementation issues, the author advises to use packet filter redirection combined with an anonymous resolver client as proposed in 4.4 using a DNS based covert channel.


35

IT-Security

Chapter 5

Conclusion This thesis describes several ways to anonymize the domain name system while maintaining (backward-)compatibility with the current domain name infrastructure. It proposes aeon - a method that aims to provide performant and transparent anonymous domain name lookups to the (computer-)system it resides on. Anonymity and anonymization enhancing technologies where introduced to the reader as well as the reason why the demand for anonymity is growing with stronger interconnectedness of our society. As of this writing, aeon was not developed and therefore there are no performance statistics available at this time. An open-source implementation of the proposal is volitional and welcome by the author. The main concept can be implemented on every networking enabled platform and operating system since it does not demand for special prerequisites. The concepts and methods presented and proposed in this thesis are subject to improve existing anonymization solutions and focuses to mitigate the risk of information leaks through the domain name service. This service was chosen because of its ubiquitous usage when accessing resources on the Internet as it will continue to be an important foundation of the world wide web. Of course, while there is no standardized way of resolving domain names anonymously, additional contributions to the domain name system may render the proposal unnecessary in future, providing a better, more secure foundation for anonymization networks and technologies.


36

IT-Security

Chapter 6

Appendix 6.1

DNS Packet: Header Fields

The following headers are referring to fig. 3.1 shown in chapter 3: ID: Identification 16 bits Used to match replies to the appropriate request since DNS over UDP is stateless. An attacker predicting this value would be able to spoof DNS replies by simply sending them before the real name server does. QR: Query/Response 1 bit Flag field. Indicates if the packet is a query or a response packet. OPCODE: Operational Code 4 bits Specifies which kind of query is transmitted within the message. AA: Authoritative Answer 1 bit Flag field. Indicates if an answer is given authoritative or not. TC: Truncated 1 bit Flag field. Indicates if only the first 512 octets of the reply was returned and the rest of the information is truncated due to the maximum payload limit. RD: Recursion Desired 1 bit Flag field. Indicates if the client wants the server to recursively resolve the requested record(s). If set by the client, the server will copy the flag to the response. RA: Recursion Available 1 bit Flag field. Indicates if the server is able and willing to recursively resolve requested record(s).


a

IT-Security

Z: 1 bit Reserved. Must be 0 in requests and replies. Originally 3 bits in size as described in [22], two bits were used for DNSSEC (see: AD and CD). AD: Authenticated Data 1 bit Flag field. Used by DNSSEC. CD: Checking Disabled 1 bit Flag field. Used by DNSSEC. RCODE: Return Code 4 bits Unsigned. Defined in RFC 1035 and 2136 with 4 bits. Extended up to 16 bits by EDNS0. Total Questions: 16 bits Unsigned Integer. Number of questions included in the questions section. Total Answer RRs: 16 bits Unsigned Integer. Number of entries in the answer resource records section. Total Authority RRs: 16 bits Unsigned Integer. Numer of entries in the authority resource records section. Total Additional RRs: 16 bits Unsigned Integer. Number of entries in the additional resource records section. Questions[]: Variable Length An array containing zero or more query structures. Each query structure is a tuple of name, type and class. The class is usually IN, the type is a valid resource record type according to their RFCs [21] [22] and names are full qualified domain names that do not contain any wildcards. This is the only variable length section used within a query message - the Answer RRs, Authority RRs and Additional RRs fields are limited to reply structures. Answer RRs[]: Variable Length An array containing zero or more Answer Resource Record structures matching the name, type and class tuple of the query structure. If there are CNAME pointers included, the according target resource records (usually type A) should be attached within the Additional RRs structure. Authority RRs[]: Variable Length An array containing zero or more Authority Resource Record structures. These are NS resource records that point to name servers closer to the target name within the domain name hierarchy. While this field is of optional nature, the content should be cached by clients in order to send consecutive queries matching the name hierachy directly to these name servers.


b

IT-Security

Additional RRs[]: Variable Length An array containing zero or more Additional Resource Record structures. These might be resolved CNAME targets as well as information selected by “next query prediction” in order to keep the load for the server down1 .

6.2

DNS Packet: Query Structure

The following fields are referring to fig. 3.2 shown in chapter 3: Query Name: Variable Length A FQDN represented as a sequence of so called labels. The full specification of labels are described in RFC 1034 [21]. Type: 16 bits The resource record type. The basic set (A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO, MX, TXT) was described in RFC 1035. If set to OPT, the protocol extension EDNS0 [25] will be used. Class: 16 bits The resource record class. For now, only ÏN¨(the Internet class) is in use.

6.3

DNS Packet: Resource Record Structure

The following fields are referring to fig. 3.3 shown in chapter 3: Resource Record Name: Variable Length Basically copied from the Query Name field of the query structure.

1

compared to the cost of spawning seperate processes to answer each consecutive query otherwise.


c

IT-Security

Chapter 7

Acronyms AES Advanced Encryption Standard APNIC Asia-Pacific Network Information Centre ASN Autonomous System Number AXFR Asynchronous Xfer Full Ranges BGP Border Gateway Protocol DHT Distributed Hash Tables DNS Domain Name System DNSSEC Domain Name System Security Extensions FQDN Full Qualified Domain Name GPU Graphics Processing Unit HTTP Hyper Text Transfer Protocol IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers IDN Internationalized Domain Name IMAP Internet Message Access Protocol IP Internet Protocol MITM Man In The Middle


d

IT-Security

NIS Network Information Service RFC Request for Comments RSA Rivest Shamir Adleman SRI Stanford Research Institute SSL Secure Sockets Layer TCP Transport Control Protocol TLD Top Level Domain UDP User Datagram Protocol


e

IT-Security

Bibliography [1] Reporters Sans Frontieres, “Press freedom index 2009,” 2010, http://en.rsf.org/pressfreedom-index-2009,1001.html, retrieved 05/10/2011. [2] ——, “Press freedom index 2010,” 2011,

http://en.rsf.org/press-freedom-index-

2010,1034.html, retrieved 05/10/2011. [3] G. Walton, Chinas Golden Shield - corporations and the development of surveillance technology in the People’s Republic of China. Rights & Democracy, 2001. [4] P. Biddle, P. England, M. Peinado, and B. Willman, “The darknet and the future of content protection,” in Digital Rights Management, ser. Lecture Notes in Computer Science, J. Feigenbaum, Ed. Springer Berlin / Heidelberg, 2003, vol. 2696, pp. 155–176. [5] R. Dingledine, N. Mathewson, and P. Syverson, “Deploying low-latency anonymity: Design challenges and social factors,” Security & Privacy, IEEE, vol. 5, pp. 83–87, 2007. [6] D. Atkins and R. Austein, “Rfc 3833: Threat analysis of the domain name system (dns),” IETF, United States, Tech. Rep., 2004. [7] C.-P. Sergio and G.-A. Joaquin, “Anonymous resolution of dns queries,” in On the Move to Meaningful Internet Systems: OTM 2008, ser. Lecture Notes in Computer Science, R. Meersman and Z. Tari, Eds.

Springer Berlin / Heidelberg, 2008, vol. 5332, pp.

987–1000. [8] F. Zhao, Y. Hori, and K. Sakurai, “Two-servers pir based dns query scheme with privacypreserving,” Intelligent Pervasive Computing, International Conference, vol. 0, pp. 299– 302, 2007. [9] ——, “Analysis of privacy disclosure in dns query,” Multimedia and Ubiquitous Engineering, International Conference on, vol. 0, pp. 952–957, 2007. [10] Y.

Lu,

“Ppdns:

Privacy-preserving

domain

name

system,”

2010,

http://www.ics.uci.edu/ yanbinl/papers/ppdns poster.pdf, retrieved 06/30/2011.


f

IT-Security

[11] P. Andreas and K. Marit, “Anonymity, unobservability, and pseudonymity — a proposal for terminology,” in Designing Privacy Enhancing Technologies, ser. Lecture Notes in Computer Science, H. Federrath, Ed. Springer Berlin / Heidelberg, 2001, vol. 2009, pp. 1–9. [12] C. D´ıaz, S. Seys, J. Claessens, and B. Preneel, “Towards measuring anonymity,” K.U.Leuven, Tech. Rep., 2002. [13] J.

Fallows,

“The

connection

has

been

reset,”

2008,

http://msl1.mit.edu/furdlog/docs/atlantic/2008-03 atlantic fallows chinese firewall.pdf, retrieved 06/24/2011. [14] Anon., Enemies of the Internet 2011. Reporters Sans Frontieres, 2011. [15] P. K. Nayar, “Wikileaks, the new information cultures, and digital parrhesia,” in Economic and Political Weekly XLV No 52, ser. Lecture Notes in Computer Science, 2010, vol. 52, pp. 27–30. [16] B.

Ackerman

and

Y.

Benkler,

“Private

mannings

humiliation,”

2011,

http://www.nybooks.com/articles/archives/2011/apr/28/private-manningshumiliation/, retrieved 07/13/2011. [17] D. Harrenstien, M. Stahl, and E. Feinler, “Rfc 952: Dod internet host table specification,” IETF, United States, Tech. Rep., 1985. [18] L. P. Deutsch, “Rfc 606: Host names on-line,” IETF, United States, Tech. Rep., 1973. [19] M. Krilanovich, “Rfc 623: Comments on on-line host name service,” IETF, United States, Tech. Rep., 1974. [20] M. Kudlick and J. Feinler, “Rfc 625: On line hostnames service,” IETF, United States, Tech. Rep., 1974. [21] P. V. Mockapetris, “Rfc 1034: Domain names - concepts and facilities,” IETF, United States, Tech. Rep., 1987. [22] ——, “Rfc 1035: Domain names - implementation and specification,” IETF, United States, Tech. Rep., 1987. [23] Anon., “Root server technical operations assn,” 2011, http://www.root-servers.org/, retrieved 07/13/2011. [24] ——, “root.zone,” 2011, http://www.internic.net/zones/root.zone, retrieved 07/13/2011. [25] P. Vixie, “Rfc 2671: Extension mechanisms for dns (edns0),” IETF, United States, Tech. Rep., 1999.


g

IT-Security

[26] D. Goldschlag, M. Reed, and P. Syverson, “Onion routing,” Commun. ACM, vol. 42, pp. 39–41, February 1999. [27] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: the second-generation onion router,” in Proceedings of the 13th conference on USENIX Security Symposium - Volume 13, ser. SSYM’04. Berkeley, CA, USA: USENIX Association, 2004, pp. 21–21. [28] R. Dingledine, “Tor hidden services,” 2005, http://www.freehaven.net/ arma/wth3.pdf, retrieved 07/14/2011. [29] B.

R.

Fischer,

“Building

an

anonymous

vpn,”

2009,

http://www.cypherpunk.at/ocat/download/Docs/thesis ocat.pdf, retrieved 07/15/2011. [30] Anon.,

“I2p:

A

scalable

framework

for

anonymous

communication,”

2010,

http://www.i2p2.de/techintro.html, retrieved 07/15/2011. [31] I. Clarke, O. Sandberg, B. Wiley, and T. Hong, “Freenet: A distributed anonymous information storage and retrieval system,” in Designing Privacy Enhancing Technologies, ser. Lecture Notes in Computer Science, H. Federrath, Ed. Springer Berlin / Heidelberg, 2001, vol. 2009, pp. 46–66. [32] M. Rogers and S. Bhatti, “How to disappear completely: A survey of private peer-to-peer networks,” in SPACE 2007 (Sustaining Privatcy In Autonomous Collaborative Environments)., 2007. [33] S. Konstantinidou and L. Snyder, “The chaos router: a practical application of randomization in network routing,” in Proceedings of the second annual ACM symposium on Parallel algorithms and architectures, ser. SPAA ’90. New York, NY, USA: ACM, 1990, pp. 21–30. [34] Anon., “anonet: Frequently asked questions,” 2006, http://anonet.org/faq.html, retrieved 08/03/2011. [35] K.

Billen,

“Anonyme

namensauflösung

u tor,” ¨ber http://hp.kairaven.de/bigb/asurf3.html, GERMAN, retrieved 08/01/2011.

2010,

[36] I. S. Moskowitz, R. E. Newman, D. P. Crepeau, and A. R. Miller, “Covert channels and anonymizing networks,” in Proceedings of the 2003 ACM workshop on Privacy in the electronic society, ser. WPES ’03.

New York, NY, USA: ACM, 2003, pp. 79–88.

[37] M. V. Horenbeeck, “Deception on the network: thinking differently about covert channels,” in Proceedings of the 7th Australian Information Warfare and Security Conference, 2006, pp. 174–185. [38] T. van Leijenhorst, K.-W. Chin, and D. Lowe, “On the viability and performance of dns tunneling,” University of Wollongong, Tech. Rep., 2008.


h

IT-Security

[39] Anon.,

“New

gtld

program:

Draft

applicant

guidbook

(draft

http://www.icann.org/en/topics/new-gtlds/draft-rfp-24oct08-en.pdf,

rfp),”

2008,

retrieved

08/08/2011. [40] D. J. Bernstein, “Cryptography in dnscurve,” 2009, http://dnscurve.org/crypto.html, retrieved 07/16/2011. [41] J. Geelan, “Moore’s law: ”we see no end in sight” says intel’s pat gelsinger,” 2008, http://java.sys-con.com/node/557154, retrieved 07/16/2011. [42] K. Jang, S. Han, S. Han, S. Moon, and K. Park, “Accelerating ssl with gpus,” SIGCOMM Comput. Commun. Rev., vol. 40, pp. 437–438, August 2010. [43] B. Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C.

New

York, NY, USA: John Wiley & Sons, Inc., 1993.


i

Towards an anonymous Domain Name System

Towards an anonymous Domain Name System

Suggest Documents

Pengantar DNS (Domain Name System)

An Efficient Anonymous Credential System

Developing an Ontology for the Domain Name System

Development of the Domain Name System* - Computer ...

Quality of Name Resolution in the Domain Name System

Chapter 24 The Domain Name System (DNS)

pdf domain name system - Google Drive

DNSSEC, Domain Name System Security Extensions - Afnic

ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM ...

Domain Name System (DNS) Security: Attacks

Domain Name System (DNS) Server - Cisco

DNSSEC, Domain Name System Security Extensions - Afnic

Quality of Name Resolution in the Domain Name System - Prasant ...

An Assessment of Internationalised Domain Name ...

Here - Domain Name Journal

DOMAIN NAME VALUATION

Domain Name Application Form

.PL DOMAIN NAME LIFECYCLE

Towards an international certificate system

Understanding DNS (the Domain Name System) - Incognito Software

Perils of Transitive Trust in the Domain Name System

Host Identity Protocol (HIP) Domain Name System (DNS) Extension

white-hat hacking across the domain name system - Google Sites

A Telephone Domain Name System (T-DNS) for Internet ... - wseas.us