New Covert Channels in HTTP

Adding Unwitting Web Browsers to Anonymity Sets

Matthias Bauer
Institut fr Informatik
Martensstrasse 3
91058 Erlangen, Germany

matthiasb@acm.org
ABSTRACT

measuring anonymity. It is the set of all possible subje ts

This paper presents new methods enabling anonymous ommuni ation on the Internet.

We des ribe a new proto ol

that allows us to reate an anonymous overlay network by

exploiting the web browsing a tivities of regular users. We
show that the overlay network provides an anonymity set
greater than the set of senders and re eivers in a realisti
threat model.

In parti ular, the proto ol provides unob-

servability in our threat model.

In the ontext of lassi-

re eivers.
Currently employed implementations of mix networks are,
for example, the Cypherpunks [34 and Mixmaster [32 remailers and the nas ent Mixminion proje t [13.

Chaum's

work motivated other s hemes whi h avoid expensive de ryption at ea h step, to minimize delay, for example, Crowds
[36 and Onion Routing [22.
In pra ti e, most users of these systems do not run mix

Categories and Subject Descriptors

nodes themselves. They ause tra patterns to and from

C.2.0 [Computer-Communi ation Networks: General

Se urity and prote tion ; K.4.1

Publi Poli y IssuesPriva y

who might ause an a tion [27.

al ommuni ation proto ols, it onsists of the senders and

[Computers and So iety:

the set of mix nodes, whi h a global, passive adversary an

use to redu e the anonymity provided by the systems. Possible atta ks by su h an observer in lude interse tion, timing
and pa ket ounting atta ks on remailers and other systems
derived from Chaumian mixes [11, 3, 35.

General Terms

lutions introdu e

Se urity

Suggested so-

into the proto ols.

a hieved mainly by having the senders inje t

sages [7, whi h are dis arded at some mix.

Unobservability is a stronger property than

Keywords

This is

dummy mes-

unlinkability,

meaning that an observer annot tell if messages are being

Covert hannel, HTTP, mix network, anonymity

1.

over tra

sent or re eived

at all.

This paper presents te hniques to enlarge the anonymity

INTRODUCTION

set by in luding noninvolved subje ts who provide over

Priva y on the Internet gains importan e as most network

tra for the proto ol in question. Our approa h is to hide

a tivity an be linked to a user's identity. Proposed solutions

ommuni ation within transit tra going through HTTP

that use Chaumian mixes show ertain tra patterns if not

browsers.

every user runs a node in the system. We des ribe a realisti

In our model, the adversary annot distinguish senders or

threat model and present a new set of proto ols that allow

re eivers in the hidden proto ol from other HTTP users on-

unobservable ommuni ation.

ta ting the same set of servers. This enlarges the anonymity

In 1981, David Chaum presented the on ept of

proto ol to provide senderre eiver

mixes,

unlinkability under stan-

set beyond senders and re eivers and provides unobservability.

dard ryptographi assumptions. Unlinkability means that

The rest of the paper is organized as follows. In Se tion 2,

an observer does not learn anything to improve her guesses

we dene our adversary model. Se tion 3 briey introdu es

on who ommuni ates with whom (The

Chaumian mixes and explains why HTTP is a good hoi e of

of two entities being related is equal to the

over proto ol. Related work is examined in Se tion 4. Se -

ability). The notion of the

tion 5 des ribes a new lass of overt hannels inside HTTP

apriori probability
aposteriori probanonymity set is essential when

whi h allow ommuni ation between servers under the over

of usergenerated tra . To show how these hannels an
be put to use in a Chaumian mix, we present a simple pro-

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
WPES03, October 30, 2003, Washington, DC, USA.
Copyright 2003 ACM 1-58113-776-1/03/0010 ...$5.00.

to ol in Se tion 6. Unsolved problems and areas for future

resear h are dis ussed in Se tion 7. We on lude with Se tion 8.

2.

THREAT MODEL

adversaries, see for example [36, [2, [20 and [6.

To mount the timing and interse tion atta ks against many

employed systems, the observer only needs to inspe t the
headers in the layers below the appli ation layer of the TCP/IP
sta k at sele ted points on the Internet.
This pre isely mat hes the apabilities of urrent (legal)
tele ommuni ation surveillan e.

To ite the CALEA

Im-

plementation Se tion of the FBI:

These

te hniques an be employed to enhan e unlinkability.

HTTP is a lientserver proto ol. At rst, this seems to
imply that hidden data an only be forwarded through a
hain of alternating lients and servers, all of whi h have
to be parti ipants of the hidden network.

We will show,

however, that ommuni ation between servers is feasable

through standard web lients whi h need not be part of the
ommunity using the overt proto ol.

examine[ing the full pa ket stream and examine

proto ol layers higher than layer 3 would pla e a
high load on existing network elements in most
ar hite tures. [41.

4. RELATED WORK
The on ept of overt hannels was introdu ed by B. Lampson in 1973 [29. Covert hannels in the network and trans-

The spe i ation of tra data in the EU Convention

port layers of the TCP/IP proto ol were examined by Row-

on Cyber rime [12 indi ates that the intended mandatory

land [38 and Fisk et al. [17. Using HTTP as substrate for

surveillan e by internet servi e providers is restri ted to the

other appli ation level proto ols is dis ussed in RFC 3205

lower three layers of the TCP/IP sta k.

[33, where only overt en apsulation of proto ols is onsid-

We grant our adversary the additional ability to inspe t

ered, naturally. There are several tools that tunnel proto ols

appli ation layer headers. This adversary model orresponds

through HTTP, mostly for ir umvention of rewalls, for ex-

to an observer who is datamining tra logs for liques of

ample, Lars Brinkho 's

ommuni ating people.

used to disguise any proto ol as HTTP tra , but the set of

This is a realisti and impending

threat.

httptunnel

entities in whi h to hide (the

[8. These tools an be

anonymity set

[27) onsists of

just the sender and re eiver, whereas the onstru tions listed

3.

BACKGROUND

in Se tion 5 use real over tra , involving unwitting web

In Chaumian mixes, nodes relay messages for ea h other.

Ea h node has a

(public key, private key)

pair.

To send a

message along a hain of relaying mixes through the mix

overlay network, the address of the nal re ipient is atta hed
to the message. The result is en rypted with the publi key
of the last node in the hain.

The address of the node is

atta hed to the result and the pro ess repeated for ea h
node along the hosen path toward the rst. On re eipt of
a message, a node de rypts it and  if it is not the nal
re ipient itself  forwards it to the node spe ied in the
de rypted text.
Later improvements on Chaum's s heme suggest random
delays, various strategies to pro ess and subsequently dis-

pat h messages (ushing) [32, 26, 35, reordering of messages in the pool, padding the messages to a xed size after
de ryption, and other improvements to ensure unlinkability.
Although re ently ontributed s hemes (e.g.

MorphMix

[37, GNUnet's GAP [4 or Tarzan [19) require users to

transport tra for other users, many deployed Chaumian
mixes and derived systems suer from the problem that most
users do not  or perhaps annot  run nodes in the systems themselves.

surfers as over. In Infranet [16, overt hannels in HTTP

are used to ir umvent web ensorship. Web servers parti ipating in the Infranet re eive hidden requests for ensored
web pages and return the pages' ontent steganographi ally
hidden in harmless images.

Goldberg and Wagner's TAZ

and rewebber network [21 implements anonymous publishing based on HTTP.

In [6, the authors briey tou h on the subje t of unobservability, but on lude that real users would inadvertedly
destroy this property. Surveys su h as Raymond's [35 mention the on ept, but do not point to proto ols that provide
it.

5. SERVERTOSERVER CHANNEL
THROUGH UNWITTING CLIENTS
In this se tion, we explain how HTTP servers an ommuni ate through lients without the onsent or knowledge
of the user. This onstitutes a new lass of overt hannel,
whi h transports data indire tly. The main me hanisms inside HTTP/HTML that allow su h data transmissions are:

They may be hindered by Network Ad-

1. Redire ts

dress Translation [40, dynami  and therefore unstable 

2. Cookies

IP addresses or restri tive rewalling poli ies. This greatly

weakens the a hievable anonymity, as a passive adversary

3. Referer

an observe tra patterns leading to and oming from the

mix network.

headers

4. HTML elements

To thwart tra analysis, we suggest hiding the proto ol inside the wellestablished HyperText Transfer Proto-

5. A tive Content

ol (HTTP[25, 18). A ording to re ent measurements[31,

HTTP a ounts for the highest per entage of data on the Internet, only slightly less than FastTra k's [15 PeertoPeer
proto ol.

These features an be employed as follows:

5.0.1 Redirects
Redire ts (RFC 2616 303 messages [25) are used to

Using HTTP as over tra brings another advantage.

There is already an extensive body of resear h, and sev-

refer the lient to another lo ation.

eral implementations, whi h aim at providing some degree

the URL of a CGI s ript, with optional parameters in the

of anonymity for HTTP lients in the presen e of various

QUERY_STRING

Communi ations Assistan e for Law Enfor ement A t

The lo ation an be

[9. This allows CGI s ripts to send data in

the typo was in the RFC and stu k.

said parameters to other CGI s ripts through the browsers of

embed sr =URL

unwitting web surfers. This hannel's apa ity is restri ted

je t to load.

Denes an embedded multimedia ob-

to 1024 URLen oded bytes [5.

5.0.2

layer sr =URL Denes a transparent layer of this page.

Cookies

Cookies onstitute a me hanism to keep state information

(key,value)
pair for further ommuni ation, a server sends a Set-Cookie:
header in the reply to a request. The value part is allowed

on the lient side. To advise the lient to keep a

If the HTML do ument is reated by a CGI s ript, the

URL

value in the tags above an be set to ontain the address of

another s ript together with parameters.
The

<META HTTP-EQUIV>

tag/attribute allows embedding

to be up to 4 kilobytes long, and the standard spe ies that

of HTTP proto ol header elds in the body of an HTTP

a lient must be able to store up to a maximum of 40 ookies

message. This is useful for our purposes, be ause the header

per server. In the servertoserver ontext, we an use op-

thus embedded in the body es apes the inspe tion of our

tional features to transport data between the servers. The

adversary dened in Se tion 2.

denition of ookies in RFC 2109 [28 denes a proto ol sub

our ontext are:

eld

domain

whi h arries information about what group of

web servers the ookie is to be sent to.

that the

Interesting appli ations in

domain

The RFC states

Redire ts (return ode 303 [25) inside su essful replies

(return ode 500):

must ontain at least two dots if it ends in

dots if it ends in a twoletter TLD. There are a many free

<META HTTP-EQUIV="Refresh"
CONTENT="3;URL=http://www.some.org/some.html">

Dynami DNS servi es online, most of whi h provide host-

This line of HTML auses the browser to request

a threeletter Top Level Domain (TLD) and at least three

some.html

names in domains with this property, e.g., all hostnames in

the zone administered by
domain. If a CGI s ript

dyndns.org are in the same ookie

on server foo.dyndns.org sends a

ookie of the form

KEY = VALUE; domain = .dyndns.org; Path = /;

bar will get foo's (key,value) pair. To
get the browser to request data obje ts from bar.dyndns.org,
the do ument requested from foo ould ontain one of the
a tive ontent that requests data from

5.0.3

bar

automati ally.

headers ontain the lo ation of the web page or

s ript that linked to the presently requested one. Sin e the

naming of ontents an be hosen arbitrarily by a server
 and for ed upon the browser by automati requests as
des ribed below in subse tion 5.0.4  this is another hannel
between servers through unwitting browsers.

The length

restri tion of redire ts applies here, too.

5.0.4

SetCookie header:
<META HTTP-EQUIV="Set-Cookie"
CONTENT="key=value;path=/;domain=.dyndns.org">

Setting ookies without a

dyndns.org

sub

domain to whi h the browser subsequently onne ts.

5.0.5

Active Content

So alled A tive Content is ode that is exe uted on

the lient. Currently used languages for a tive ontent are
SUN's Java [24, Nets ape's JavaS ript [10, Ma romedia's

Referer

Referer

after 3 se onds.

transmitted to every server in the

then

tags mentioned below under HTML elements, or ontains

www.some.org

This line sets a ookie on the browser, whi h will be

to a browser and the browser onne ts to server

bar.dyndns.org,

from

Flash [1 and Mi rosoft's A tiveX [30, the latter being restri ted to a single browser, so it will not be dis ussed here.
In Java's design, onsiderable eort was made to make the
exe ution of untrusted ode on the lient se ure. Java's se urity framework inhibits onne tions to servers diering from
the one whi h supplied the running applet, so it annot be
used to transmit data to dierent servers. Of the remaining two languages, we hose Javas ript, be ause it is more
widespread and better do umented. Running ode on un-

HTML Elements

The HyperText Markup Language (HTML) version 4 ontains elements that ause most browsers to automati ally
request given do uments from HTTP servers. The following
HTML tags and attributes have this property:

suspe ting surfer's ma hines opens a number of hannels of

varying bandwidth between s ripts on servers. To name two
examples:

It is trivial to program redire ts to CGI s ripts (with

parameters) in JavaS ript.

frame sr =URL

Indi ates a part of a

iframe sr =URL
img sr =URL

frameset.

FORM

[42, ll the

POST

request without user intera tion.

This hannel allows almost arbitrarily large payloads.

Indi ates that JavaS ript (see below)

fun tions for this page should be loaded from

link href=URL

A s ript may onstru t an invisible

the body of a

Denes an inline image.

s ript sr =URL

elds with data and send all of it to a CGI s ript in

Denes an embedded frame.

URL.

All the above me hanisms are heavily relied on by authors

of HTML do uments and CGI s ripts.

Indi ates outofband information for

the urrent page.

obje t sr =URL Denes an embedded multimedia obje t to load.

applet odebase=URL

6. THE MUTED POSTHORN A CHAUMIAN MIX ON BANNER ADVERTS

To demonstrate how a anonymous messaging proto ol an

Indi ates that Java (see below)

lasses for this page should be loaded from

URL.

use HTTP as over tra to a hieve unobservability against

our adversary, we present a simple Chaumian mix.

6.1 The Setup

A re eiving node tries to de rypt the message with its se-

In our variant of Chaum's proto ol, the

Muted Posthorn,

four (not ne essarily disjoint) groups of entities are involved:

The node maintainers provide CGI s ripts on HTTP

servers. The s ripts work as mix nodes and so every

s ript has a

(publickey, secretkey)

pair and a pool for

ret key. If de ryption su eeds, the resulting text is parsed

for headers.
If it is a

Get

message, the node looks up the requested

mailbox. If it exists, the node throws a oin. On

0,

the on-

tent is sent  through the requesting lient  as a message

to a random node in the mix network. The lient an ex-

messages to be forwarded. A s ript is alled with the

tra t the message, for example, from its lo al browser a he.

message as the parameter of a POST request.

On

The

1,

a xed HTML response is sent to the lient. If the

s ripts work as in Chaum's mix networks, i.e. on re-

mailbox does not exist, again a oin is tossed, this time to

eipt of a message, they de rypt it and look at headers

de ide whether to send a randomly hosen message from the

spe ifying further pro essing. In our simple proto ol,

pool through the lient or the HTML response.

there are three possible a tions, forwarding the message to another node, storing the message in a lo al

If it is a

To

message, the address is examined. If it is a

mailbox number, the message is stored in it. If the addressee

mailbox with a supplied name (a 128 bit number), and

is a URL, the message is put in the message pool for further

sending the ontent of a given mailbox ba k to the re-

delivery. Again, a oin throw de ides whether a randomly

questing HTTP lient. The outward visible a tion of

hosen message from the pool or the xed HTML response

the s ripts is to return either an HTML do ument with

is returned to the lient.

JavaS ipt ode that submits data to another node, or

Against a passive observer as the adversary dened in

Se tion 2, this proto ol provides unobservability. Senders of

a short, stati HTML do ument.

messages and requesters of mailboxes send HTTP GET reThe linkers maintain web pages whi h all seem to ontain

the same small i on or banner advert.

by in luding an

iframe

one of the nodes.

quests as any harmless lient. Upon re eipt of the JavaS ript

They do this

do ument, they substitute their own messages for the ones

whi h in ludes a frameset on

set inside the JavaS ript ode, and then let the browser

The frameset onsists of a frame

with the image and a se ond, invisible frame.

This

exe ute the ode.

An observer who is restri ted to the

IP/TCP/HTTP headers thus annot distinguish between

frame is reated by a node and either ontains the

harmless browsers and senders/re eivers. This in reases the

JavaS ript ode that does the a tual transport, or the

anonymity set by the noninvolved web surfers.

short HTML do ument.

The senders and re eivers use this setup to ommuni-

ate en rypted messages. Senders onstru t messages

as in re ent mix networks, e.g. Mixmaster [32, but the
nal delivery address of a message is always a mailbox
on a node, and spe ial a tions must be taken for the
rst hop in a hain.

A message thus onstru ted is

sent to the rst of the nodes in the hain by sending

a POST request to a s ript. Re eivers must pull their
mailboxes. They do this by sending en rypted send
mailbox number N requests to the nodes where they
keep mailboxes.

The simple proto ol above is sus eptible to a trivial denial of servi e atta k. An adversary an simply request the
frameset from a node repeatedly to drain its message pool.
To defend against this atta k, we introdu e a knowledgements for re eived messages (ACKs) between the nodes.
Ea h message is kept in the pool and is resent until an
ACK for the message is re eived. ACKs are not sent immediatly, but are put in the message pool themselves.
An ACK should be tied to the message it a knowledges
and to the node the message was addressed to, to avoid
forged ACKs and replays.

Hapless web surfers just visit the pages maintained by

the linkers.

6.3 DoS attack on the first protocol

Their browsers exe ute the JavaS ript

The standard approa h would

be to sign ACKs with the node's se ret key. But deploying

digital signatures at all would imply that the nodes know

ode returned by the node, transfering messages in the

ea h other's publi keys.

pro ess.

ever, shows that knowledge about su h a global state of the

Experien e with remailers, how-

mix network is hard to a hieve. For this reason we would

6.2 A first Version

like to avoid all publi key operations at the nodes, ex ept

A simple variant of our proto ol uses two kinds of messages:

To:

Our suggestion is to send the hash of the de rypted text as

ACK to the previous node (to make them indistinguishable

messages ontain en rypted messages to nodes in the

from other messages, ACKs are padded with randomness to

network.

the xed message size).

Get:

messages request mailboxes from nodes.

ness. When preparing a message

m0

for a sequen e of nodes

the sender re ursively omputes

mi+1 = To :||ni ||Eni (mi ).

where

The original sender knows all in-

termediate messages on the path, sin e she onstru ts them

Messages are always padded to a xed length with random-

ni ,

de ryption.

En (m)

m for n's publi key. For

To header is omitted. The sender submits

en rypts message

the last node, the

the en rypted message to the last node in a POST request.

layer by layer. So she an inform every node on the path

about what ACK to expe t. She does this by in luding the
ACKs as values of additional

A k headers.

The rule for on-

stru ting the next layer is now:

mi+1 = To :||ni ||Ack :||h(mi )||Eni (mi ).

A node keeps three tables: the message pool of outgoing
messages, a list of outstanding ACKs and a list of mailboxes
(see gure 1).

Message Pool:
To: node1 E_node1(mess1)
Ack: node2

a randomly hosen node, if a lient onne ts but the node's

Ack:
Pad

ack1, ack2

Pad

To: node2 E_node2(mess2)

bat hing strategy does not dispat h a message from the pool.
This would allow reuse of most of the known pooling algo-

0x123456

rithms.

0xabcdef

The time a message spends in the mix network before nal

delivery is dependent on external fa tors, namely the whims

Pad

and in linations of unknown web surfers, and the willingness

of website maintainers (linkers) to pla e links to the nodes
on their pages. Should all the linker's pages be ome unpop-

Mailboxes:

ular at some point, ommuni ation would stop entirely.

mbox1:
mbox2:

message_a

Pad

message_b

One way around this problem would be to ombine the

mix network with an Internet advertising ompany.

Pad

advertisements (pla ed in

IFRAMEs)

The

would show ads while

at the same time transporting data between the dierent

Figure 1: The internal state of a node: message pool

servers of the advertising ompany. If ookies are used as

with messages and a knowledgements for re eived

the hannel of ommuni ation, it would not be noti eably

messages, ACK table with outstanding ACKs and

dierent from what Double li k In . is doing now [14.

referen es to messages in the pool, and the mailboxes.

Can we a hieve unobservability against a global observer

who inspe ts omplete data payloads, instead of just the

headers? Universal reen ryption [23 oers a solution.

On re eipt of a message, a node he ks if it is an a knowledgement.

This is done by inspe ting the rst

of the message, where

|h()|

bits

is the ryptographi hash fun tion

used for ACKs. The resulting blo k is he ked against the

table of outstanding ACKs. If the blo k mat hes, the ACK

In universal reen ryption, a third party (the unwitting

lients, in our ase) an hange the random fa tor in a probabilisti publi key en ryption, and the following properties
hold:
1. The third party does not need to know the publi key

itself and the message orresponding to it are removed from

with whi h the message is en rypted.

the table and the pool, respe tively. Note that the URL of
the sending node is transmitted by the lient in the
header.
When pro essing

To

Referer

2. For two given en rypted messages, after reen ryption,

an adversary annot tell whi h of the outputs orre-

messages, the node now reates an

entry in its ACK table with the value of the

A k

sponds to whi h original en ryption.

header.

The node omputes the hash of the de rypted message and

In [23, P. Golle et al.

onstru ts an ACK message for the node that sent the mes-

an be implemented with ElGamal and a publi

show how universal reen ryption

sage

Generator)

(Group,

pair. They also show how reen ryption an be

extended to hybrid en ryption s hemes, where the publi

6.4 Properties of the Protocol

key s heme is used to en rypt a session key and the message

The proto ol inherits pra ti al advantages from HTTP.

All transa tions of senders, re eivers and unwitting web
surfers an be performed through HTTP anonymizing systems su h as Anonymizer [2, Crowds [36 or JAP [6.
The proto ol's tra is typi ally not blo ked or modied

itself is en rypted with a symmetri ipher and the session

key.
Unfortunately, JavaS ript has no builtin fun tions for
arithmeti of large numbers nor symmetri iphers, and implemented in JavaS ript, they would be extremely slow.

math.BigInteger and Se ureRandom

at rewalls, and passes though Network Address Translation

Java, however, oers the

[40 without problems.

lasses ne essary for implementing the reen ryption algo-

The oin tossing on the nodes makes the autosubmits

rithm. In onsistent with the se urity requirements of Java,

For a xed

standard browser implementations allow JavaS ript to all

message size of four kilobytes, the resulting tra for the

publi methods and variables of Java obje ts. JavaS ript in

terminate after two repetitions, in the mean.

lient is about the same as that for a banner advertisement

turn an be used to submit the reen rypted message to the

(typi ally 16 kb).

next node, as in the proto ol above.

7.

delivered to the lient and another randomlooking message

The global observer would see a randomlooking message

UNSOLVED PROBLEMS AND DIRECTIONS FOR FUTURE RESEARCH

of ElGamal (and the symmetri ipher in the ase of hybrid

from the lient to the next node. Be ause of the properties

Although the idea of a mix network with an enlarged

en ryption), the observer annot distinguish real messages

anonymity set seems promising, a number of open problems

from randomness. Be ause of the properties of universal re

and possible enhan ements must be dis ussed.

en ryption, she an only guess whether the outgoing message

Do a knowledgements (or la k thereof ) introdu e new points

of atta k? If a node does not re eive an ACK for a message,

message substituted by the lient. Inspe tion of the HTTP

it will re-send the message at some later time. The repeat-

body does not help to distinguish senders and re eivers from

ing pattern marks it as being a message as opposed to an

unwitting web surfers.

ACK or randomness.

User behaviour inuen es the timing of message delivery.

is a reen ryption of the re eived one or a ompletely new

Universal reen ryption also remedies the problem of repeated messages, mentioned above.

The node would re

This ould lead to a Tri kle [39 atta k. To redu e this inu-

en rypt the message in the pool before sending, so that ob-

en e, a node ould send randomness of appropriate size to

servable messages are always dierent.

8.

SUMMARY

[11 Cottrell, L. Mixmaster and remailer atta ks.

http://www.obs ura. om/~loki/remailer/

remailer-essay.html, 1994.

Priva y is of growing on ern for users of the Internet's

servi es. Existing priva y enhan ing te hnologies an assure
anonymity only if the anonymity set is su iently large.

[12 Coun il of Europe. Convention on yber rime. Te h.

rep., European Union, 2001. available from

In most urrent proto ols, the size of the anonyity set is

http:// onventions. oe.int/Treaty/en/Treaties/

Html/185.htm.

bounded by the number of the a tive users of a proto ol.

After dening a reasonable adversary model, we showed how
the anonymity set of a proto ol an be enlarged by having

[13 Danezis, G., Dingledine, R., and Mathewson, N.

Mixminion: Design of a Type III Anonymous

nonparti ipants generate over tra . We presented new

Pro eedings of the 2003 IEEE

Symposium on Se urity and Priva y (May 2003).
Remailer Proto ol. In

overt hannels in the most widespread proto ol on the

Internet, the HyperText Transfer Proto ol, and pro eeded
to des ribe a simple Chaumian mix based on CGI s ripts,

[14 Double li k, I. DART.

in whi h the anonymity set onsist of senders, re eivers and

unknowing parti ipants, thereby enhan ing anonymity for

http://www.double li k. om/us/ orporate/

priva y/priva y/internet-ads/dart.asp, 2003.
KaZaA BV. http://www.fasttra k.nu/.

the senders and re eivers. We explained remaining problems

[15

of our proto ol and suggested areas for future resear h.

[16 Feamster, N., Balazinska, M., Harfst, G.,

Balakrishnan, H., and Karger, D. Infranet:

9.

Cir umventing Censorship and Surveillan e. In

ACKNOWLEDGEMENTS
We thank Niels Provos, Marius Aamodt Eriksen, Andrei

Serjantov and Roger Dingledine for helpful suggestions and

omments.

Pro eedings of the 11th USENIX Se urity Symposium

(San Fran is o, CA, August 2002).

[17 Fisk, G., Fisk, M., Papadopoulos, C., and Neil, J.
Eliminating Steganography in Internet Tra with
A tive Wardens. In

10. REFERENCES
http://www.openswf.org/spe .html.
http://www.anonymizer. om/.

Authenti ation . RFC, Internet Engeneering Task

atta ks and trade-os in anonymity providing

Information Hiding (IH 2001)

S., Lea h, P., Luotonen, A., and Stewart, L. HTTP

Authenti ation: Basi and Digest A ess

[3 Ba k, A., Mller, U., and Stigli , A. Tra analysis

systems. In

(2001), I. S.

Moskowitz, Ed., Springer-Verlag, LNCS 2137,

pp. 245257.

http:
//www. ypherspa e.org/adam/pubs/traffi .pdf.
[4 Bennett, K., and Grotho, C. GAP  pra ti al

Pro eedings of Priva y

Enhan ing Te hnologies workshop (PET 2003 )

anonymous networking. In

(Mar h 2003), R. Dingledine, Ed., Springer-Verlag,

LNCS 2760.

For e, June 1999. RFC 2617.

[19 Freedman, M. J., and Morris, R. Tarzan: A

peertopeer anonymizing network layer. In Pro . of

the ACM Conferen e on Computer and
Communi ations Se urity (CCS2002) (November
2002).

[20 Gabber, E., Gibbons, P., Matias, Y., , and Mayer, A.

How to make personalized web browsing simple,
se ure, and anonymous. In

Cryptography 97

Pro eedings of Finan ial

(February 1997), Springer. LNCS

1318.
[21 Goldberg, I., and Wagner, D. TAZ servers and the

[5 Berners-Lee, T., Masinter, L., and M Cahill, M.

Uniform resour e lo ators (URL). RFC, Internet
Engineering Task For e, De ember 1994. RFC 1738.
[6 Berthold, O., Federrath, H., and Kpsell, S. Web

rewebber network: Enabling anonymous publishing on

the world wide web.

Communi ations of the ACM 42,

internet a ess. In

(February 1999).

Ed., Springer, pp. 115129. LNCS 2009.

[7 Berthold, O., and Langos, H. Dummy tra against
long term interse tion atta ks. In

Priva y Enhan ing

(2002), R. Dingledine and

P. Syverson, Eds., Springer-Verlag, LNCS 2482.

[8 Brinkho, L. GNU httptunnel.

http://www.no rew.org/software/httptunnel.html.

[9 Coar, K. A. L., and Robinson, D. The WWW

http://
gi-spe .golux. om/draft- oar- gi-v11-03.txt,

Common Gateway Interfa e, version 1.1.

June 1999.
[10 Corp., N. C. Core JavaS ript Guide 1.5.

http://developer.nets ape. om/do s/manuals/js/

ore/jsguide15/ ontents.html, 2000.

4 (August 1998).

Onion routing for anonymous and private internet

onne tions.

Designing Priva y Enhan ing

Te hnologies. Pro . Workshop on Design Issues in
Anonymity and Unobservability (2001), H. F. (Ed.),

First Monday 3,

[22 Golds hlag, D. M., Reed, M. G., and Syverson, P. F.

MIXes: A system for anonymous and unobservable

Te hnologies (PET 2002)

(2002),

[18 Franks, J., Hallam-Baker, P., Hostetler, J., Lawren e,

[1 Agen y, V. M. D. SWF format spe i ation.

[2

Information Hiding 2002

Springer, pp. 1835.

[23 Golle, P., Jakobsson, M., Juels, A., and Syverson, P.

Universal re-en ryption for mixnets. preprint at

https://www.rsase urity. om/rsalabs/staff/

bios/mjakobsson/univren /univren .ps, 2003.

[24 Gosling, J., Joy, B., Steele, G., and Bra ha, G. The
Java Language Spe i ation.

java.sun. om/do s/books/jls/.

[25 Irvine, U., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Lea h, P., and Berners-Lee, T.
Hypertext transfer proto ol  HTTP/1.1.

http://www.ietf.org/rf /rf 2616.txt,

June 1999.

RFC 2616.
[26 Kesdogan, D., Egner, M., and Bs hkes, T.
Stop-and-go MIXes providing probabilisti anonymity
in an open system. In

Information Hiding (IH 1998)

http://www. l.
am.a .uk/~fapp2/ihw98/ihw98-sgmix.pdf.

(1998), Springer-Verlag, LNCS 1525.

[27 Khntopp, M., and Ptzmann, A. Anonymity,

H. Federrath, Ed., Springer-Verlag, pp. 1029. LNCS

unobservability, and pseudonymity  a proposal for

terminology. In

Te hnologies

Designing Priva y Enhan ing

2009.
[36 Reiter, M. K., and Rubin, A. D. Crowds: anonymity

(July 2000), Springer.

[28 Kristol, D., and Montulli, L. HTTP state management

me hanism.

http://www.ietf.org/rf /rf 2109.txt,

for Web transa tions.

TISSEC 1,

1 (Nov. 1998), 6692.

[37 Rennhard, M., and Plattner, B. Introdu ing

MorphMix: Peer-to-Peer based Anonymous Internet

February 1997. RFC 2109.

[29 Lampson, B. W. A note on the onnement problem.

Communi ations of the ACM 16,

In Designing Priva y Enhan ing Te hnologies:

Pro eedings of International Workshop on Design
Issues in Anonymity and Unobservability (2001),

10 (O tober 1973),

Pro eedings of the

Workshop on Priva y in the Ele troni So iety

Usage with Collusion Dete tion. In

(Washington, DC, USA, November 2002).

613615.

http://
a tivex.adsp.or.jp/english/spe s/overview.htm.

[30 Mi rosoft A tiveX (TM) development kit.

[38 Rowland, C. H. Covert hannels in the TCP/IP

[31 Modeling, N., and Proje t, S. Distributions of tra

[39 Serjantov, A., Dingledine, R., and Syverson, P. From a

proto ol suite.

First Monday 2,

5 (May 1997).

stratied by appli ation. Te h. rep., Cooperative

tri kle to a ood: A tive atta ks on several mix types.

Asso iation for Internet Data Analysis (CAIDA),

In

Pro eedings of Information Hiding Workshop (IH

2002) (O tober 2002), F. Petit olas, Ed.,

September 2002.

Springer-Verlag, LNCS 2578.

[32 Mller, U., and Cottrell, L. Mixmaster Proto ol 

[40 Srisuresh, P., and Holdrege, M. IP Network Address

Version 2. Unnished draft, January 2000., 2000.

http://www.eskimo. om/~rowdenw/ rypt/Mix/

draft-moeller-mixmaster2-proto ol-00.txt.

Translator (NAT) Terminology and Considerations .

RFC, Internet Engineering Task For e, August 1999.

[33 Moore, K. On the use of HTTP as a substrate. Te h.

rep., Internet Engineering Task For e, February 2002.

Report to the federal ommuni ations ommission on

RFC 3205.
[34 Parekh, S. Prospe ts for remailers.

First Monday 1,

http:
//www.firstmonday.dk/issues/issue2/remailers/.
(August 1996).

[35 Raymond, J.-F. Tra analysis: Proto ols, atta ks,

design issues and open problems.

RFC 2663.
[41 Tele ommuni ations Industry Asso iation, C. T. .
surveillan e of pa ket-mode te hnologies, September

http://www.tiaonline.org/poli y/filings/
JEM_Rpt_Final_092900.pdf.
2000.

[42 W3C, W. W. W. C. HTML 4.01 spe i ation.

http://www.w3.org/TR/html4/,

1999.