[4751] in WWW Security List Archive
Two-way Web anonymizing (fwd)
daemon@ATHENA.MIT.EDU (Daniel Rinehart)
Mon Mar 10 23:44:03 1997
Date: Mon, 10 Mar 1997 20:57:05 -0500 (EST)
From: Daniel Rinehart <danielr@ccs.neu.edu>
To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Date: Wed, 26 Feb 1997 10:15:26 -0800 (PST)
From: Raph Levien <raph@acm.org>
In many ways, Web anonymizing is the dual of e-mail anonymizing. Both
types protect the anonymity of the party initiating the transfer.
However, since e-mail is push and the Web is pull, it protects the
anonymity of the _provider_ of e-mail information, but the _recipient_ of
Web information.
Two-way e-mail anonymizers have proven to be an invaluable tool for
protecting the free flow of information and allowing anonymous parties to
participate more fully in the dialog of the Internet. It's gratifying to
see that we now have three distinct types of two-way e-mail anonymizers,
each with its own strengths (I refer, of coure, to the nym.alias.net type
of nymserver, the continuation of penet's legacy by anon.nymserver.com
and others, and the Web-to-email gateways such as hotmail and
mailmasher).
Here, I propose a simple technique for two-way Web anonymizing, which
protects the anonymity of Web servers as well as browsers. I wouldn't be
surprised if other people have come up with the same idea already. But it
seems like the time might be ripe to actually implement it.
The core of the idea is for the anonymizing server to incorporate a
database mapping the pseudonym of the Web server to the actual address.
Thus, of the three models of two-way e-mail anonymity, it's most similar
to the penet one.
I'll give an example in more detail. Since cookies are such a
controversial topic, let's say that J. Baker wants to post the secret
Neiman-Marcus cookie recipe up on the Web, but doesn't want the NSA to be
able to track him down. Thus, he sets up a clandestine Web server, with
the cookie recipe accessible at, say,
http://student.umich.edu:9999/cookie.html. If he were to make this URL
public, then it would be anonymously accessible through, say,
http://webanon.com/http://student.umich.edu:9999/cookie.html. However, J.
prefers not to publicize his URL. Thus, he registers the following
mapping with the anonymizer at webanon.com:
http://cookie.taz/ -> http://student.umich.edu:9999/
He then publicizes the cookie.taz URL, and the public can access the
recipe at:
http://webanon.com/http://cookie.taz/cookie.html
That's the core of the idea. There are a few variations which will
help to improve the security a bit more.
First, both Web connections should probably be protected by SSL. This
won't help much against real traffic analysis, but will at least protect
J.'s identity from someone running a packet sniffer at umich. Similarly,
J.'s server can be configured to only accept requests from legitimate
anonymizers, either through a simple DNS access list or through SSL
client authentication.
Second, some protection against traffic analysis may be had through
caching. The attack is as follows: the attacker continually reloads
the cookie recipe, and looks at the outgoing Web connections from
webanon.com. If the number of accesses to umich increases during the
times the cookie recipe is accessed, then it's likely that that's where
the page is really hosted. However, with caching, a burst of accesses to
the cookie page would result in only one connection to umich, which would
probably be hard to separate from the noise.
As always when dealing with Web caching, there are a few tricky
details. For example, J. would have to tell the server to ignore "Pragma:
no-cache" requests from the browser. In addition, this protection against
traffic analysis is incompatible with forms and other types of Web
interactivity.
The other big can of worms is how to handle a network of anonymizers,
rather than a single anonymizing server. For one, chaining becomes
entirely feasible. This can be done in a couple of ways.
The first way requires no more implementation. J. registers this
mapping with webanon.com:
http://cookie.taz/ -> https://anon.middle.com/http://zzzyxx.taz/
and this mapping with anon.middle.com:
http://zzzyxx.taz/ -> https://student.umich.edu:4433/
Another method would be to use something analogous to a reply block.
J. registers this mapping with webanon.com:
http://cookie.taz/ -> https://anon.middle.com/
E_middle(http://student.umich.edu:4433)
where E_middle(m) represents the encryption of m with anon.middle.com's
public key.
The latter technique is more analogous to the reply block mechanism of
the nym.alias.net style of nymservers. It would require slightly more
implementation work in the anonymizing server (public key decryption of
the request), and would also require some client software to build the
reply blocks (in the non-chained case, I envision registering the
mappings through a simple forms-based Web interface).
There's also the matter of chaining the encryption of the Web page. I
can see the page encrypted at the last server in the chain (or better yet,
J.'s server itself), and decrypted at each step in the chain. This would
be analogous to the Encrypt-Key: function of the anonymous remailers.
This would _certainly_ require client software at J.'s end. Perhaps the
best approach would be to distribute a package containing both a
clandestine Web server (hopped up with the extra encryption features) and
the client software needed to create the chains and register them with
the Web anonymizers.
It might be worthwhile to coordinate the namespaces of anonymous
servers. If a browser is configured to use a web anonymizer as a proxy,
then the URL http://cookie.taz/ will just work. However, it would be nice
if this URL brought up the same page no matter which server was used as a
proxy. This is particularly important if servers are thought of as
temporary, movable installations rather than permanent bastions (i.e. the
"soft node" vs. "hard node" distinction of Eric Hughes).
Managing such a namespace is pretty tricky, and beyond the scope of
this post, but is probably feasible. I look forward to seeing links of the
form "http://whatver.taz/, see the webanon list for a reliable server."
Finally, a few words about the political climate for this kind of
server. There's good reason to be optimistic. First, the pull nature of
the Web makes it far more difficult to mount the traditional e-mail spams
that have plagued the remailers. Second, there's precedent that the
existence of this type of server should be protected. Even the CDA, as
horrible as it is, makes a specific exemption for intermediate Internet
servers, including the storage and dissemination of illegal materials
from caches.
It would seem that the main limitation would be resources; these
anonymizers would be certain to chew up large amounts of bandwidth. In my
opinion, the best way to deal with this issue is to put Jef Poskanzer's
throttling technology into the anonymizing server (as implemented in
thttpd). Restrict the total bandwidth to a manageable fraction of your
Internet connection, and give text files priority over images.
I think this idea could work. Comments and suggestions are welcome.
Raph
