12.4 Anonymous browsing


12.4    Anonymous browsing

In this section, we overview and discuss some technologies that can be used to protect the privacy of Web users and to provide support for anonymous browsing accordingly . In particular, we overview and briefly discuss anonymizing HTTP proxy servers, JAP, Crowds, onion routing, and the Freedom Network.

12.4.1    Anonymizing HTTP proxy servers

In short, an anonymizing HTTP proxy server is an HTTP proxy server that removes all parts of an HTTP request message that ”directly or indirectly ” reveals information about the browser, but are not really required by the Web server to serve the request and to respond appropriately. Most importantly, an anonymizing HTTP proxy server can hide the browser s IP address. If the Web server sends back the requested resource, it can be forwarded by the anonymizing HTTP proxy server to the browser. Similarly, the Web server need not learn anything about the client platform and browser in use.

Most anonymizing HTTP proxy servers work with nested URLs. [13] A nested URL is an URL in which the document part refers to another URL. For example, in a nested URL of the form

http://proxy.../http://www.esecurity.ch

the document part (i.e., http://www.esecurity.ch) refers to another URL. By retrieving the nested URL, the browser first connects to the HTTP proxy server running at proxy... , and this proxy server connects to the Web server at http://www.esecurity.ch. Similar to anonymous remailers, the use of anonymizing HTTP proxy servers can also be chained and a cascade of corresponding servers may be used. This is important if there is no single proxy server a user is willing to trust.

The following example illustrates a nested URL that is forwarded by two proxy servers (i.e., proxy1... and proxy2... ) before it is finally delivered to the Web server:

http://proxy1.../http://proxy2.../http://www.esecurity.ch

Obviously, each proxy server in the chain removes its part of the nested URLs. This means that the Web server finally sees only the resource that is requested and the IP address of the last proxy server in the chain. There is no possibility for the Web server to determine what browser originally requested the resource, or on what proxy chain the request message was delivered. Each proxy server, however, holds some local state information about the established connections (on either side of the proxy). Consequently, any response message from the Web server can be sent back to the browser using exactly the same proxy chain (in reverse order).

If an anonymizing HTTP proxy server is not chained, it can be complemented by the SSL/TLS protocol to improve its ability to provide anonymity services to its users. In fact, the anonymizing HTTP proxy server can either tunnel or proxy the SSL/TLS-protected data traffic between the browser and the Web server. In the second case, the connection between the proxy server and the Web server may or may not be protected using the SSL/ TLS protocol (in addition to the use of the SSL/TLS protocol between the browser and the proxy server).

There is an increasingly large number of companies and organizations that operate anonymizing HTTP proxy servers and provide corresponding anonymity services for Web users. Two examples include Anonymizer.com [14] and IDzap, LLC. [15] Most of these services have versions in which they support the SSL/TLS protocol in one way or another.

12.4.2    JAP

A group of researchers at the University of Technology Dresden adapted the notion of a Chaum mixing network for the WWW and designed and developed a corresponding system that can be used to anonymously browse through the Web. The system is named JAP and its open source software is entirely written in the Java programming language. [16]

In essence, the JAP system implements a Chaum mixing network for HTTP. Each Chaum mix is represented by a piece of software (i.e., an anonymizing HTTP proxy server) that a JAP user must install and configure locally. This software acts as a local JAP proxy server to the browser.

When the user wants to anonymously request a resource from a Web server using the JAP system, the browser must forward the request to the local JAP proxy server. The JAP proxy server, in turn , must encrypt the request message multiple times (once for every JAP proxy server on the request message s delivery path to the Web server). The encrypted message is then sent through the defined chain of intermediate JAP proxy servers to the Web server, and the Web server sends back the requested resource. The procedure is identical to the one described in Section 12.2 for the delivery of anonymous messages in a Chaum mixing network.

12.4.3    Crowds

In the late 1990s, a group of researchers at AT&T Research designed and prototyped a sophisticated system to provide anonymity services for Web users [11, 12]. The system was named Crowds . This is because the system operates by grouping users into a large and geographically diverse group (a so-called crowd ). The basic idea of Crowds is to probabilistically chain multiple anonymizing HTTP proxy servers, and to encrypt all data that is sent forth and back between the proxy servers. The fact that the chaining is probabilistical differentiates Crowds from many other systems, including, for example, the JAP system mentioned above.

In the Crowds systems, each user is represented by a process ”a so-called jondo [17] ”that runs on his or her system. When this process is started, it contacts a server called the blender to request admittance to the crowd. If admitted, the blender reports to the jondo the current membership status of the crowd and information that enables the jondo to actually participate in the system. The user, in turn, must configure the jondo to serve as proxy server by specifying its hostname and port number in his or her browser as the proxy for all services (i.e., Gopher, HTTP, and SSL). Afterwards, any request originating from the browser is sent directly to its jondo. Upon receiving the first request, the jondo establishes a random path of jondos to and from the Web server. More precisely, the jondo picks a jondo from the crowd (possibly itself) at random, and forwards the request to it. When this jondo receives the request, it flips a biased coin to determine whether or not to forward the request to another jondo. If the result is to forward, then the jondo selects a random jondo and forwards the request to it. Otherwise the jondo submits the result to the Web server for which the request was destined originally. Consequently, each request travels from the user s browser, through a number of jondos, and finally to the Web server. Subsequent requests initiated at the same jondo follow the same path (except perhaps going to a different Web server), and server response messages traverse the same path as the request messages, only in reverse.

All communications between any two jondos is encrypted using a key known only to the two jondos. Encryption keys are established as jondos join the crowd. Therefore, some group membership procedures must be defined and put in place. These procedures determine who can join the crowd and when they can join, and inform members of the crowd membership accordingly. In fact, there are many schemes and corresponding group membership protocols that can potentially be used to manage crowd memberships. While providing robust and reliable distributed solutions, many of these schemes have the disadvantage of incurring significant overhead and providing semantics that are arguably too strong for the application at hand. In the Crowds system, a simpler and centralized solution is used. As mentioned above, membership in a crowd is controlled and reported to crowd members by the blender. To make use of the blender (and thus the crowd), the user must establish an account with the blender (i.e., an account name and password that the blender stores). When the user starts a jondo, the jondo and the blender use this shared secret (the password) to authenticate each other s communication. As a result of this

communication, the blender may accept the jondo into the crowd, add the new jondo (i.e., its IP address, port number, and account name) to its list of current members, and report this list back to the jondo. In addition, the blender may also generate and report back a list of shared keys, each of which can be used to authenticate another member of the crowd. The blender then sends one key of the new jondo to each other jondo that is intended to share it (encrypted under the account password for that jondo) and informs the other jondos of the new member. At this point all members are equipped with the data they need for the new member to participate in the crowd.

Each member maintains its own list of crowd members. This list is initialized to that received from the blender when the jondo joins the crowd, and is updated when the jondo receives notices of new or deleted members from the blender. The jondo can also (autonomously) remove jondos from its list of crowd members, if it detects that the corresponding jondos have failed. This allows for each jondo s list to diverge from others lists if different jondos have detected different failures in the crowd.

Obviously, a major disadvantage of this centralized approach to group membership management is that the blender is a TTP for the purposes of key distribution and membership reporting. Techniques exist for distributing trust in such a TTP among many replicas, in a way that the corruption of some fraction of the replicas can be tolerated [13]. In its present, nonreplicated form, however, the blender is best executed on a trusted computer system (e.g., with log-in access available only at the console). Note, however, that even though the blender is a TTP for some functions, HTTP traffic is not generally routed through the blender, and thus a passive attack on the blender does not immediately break Web transaction security. Moreover, the failure of the blender does not interfere with ongoing transactions. It is planned that in future versions of Crowds, jondos will establish mutually shared keys using the Diffie-Hellman key exchange, where the blender serves only to authenticate and distribute the Diffie-Hellman public values of the Crowds members. This will eliminate the present reliance on the blender for key generation. Another possibility would be the use of Kerberos or any other authentication and key distribution system.

In practice, firewalls present a problem for the deployment of Crowds. Remember from the description given above that jondos are identified by their IP addresses and port numbers . Most corporate firewalls do not allow incoming connections on ports other than a few well-known ones. Thus, a firewall will generally prevent a jondo outside the firewall from connecting to another jondo inside the firewall. It is conceivable that if Crowds becomes widespread, and there is demand for a special reserved port, that firewalls will open this port and allow jondos to communicate accordingly. Until then, Crowds will be most useful across academic institutions, as a service provided by ISPs to private subscribers, and within very large organizations (because they traditionally do not use firewalls).

Crowds 1.0 is implemented in Perl 5.0. According to their developers, Perl was chosen for its rapid prototyping capabilities and its portability across UNIX and Microsoft platforms. Obviously, the performance of Crowds could be improved by implementing the system in a compiled language, such as C or C++. [18] Further information and the corresponding software can be obtained from the Crowds home page. [19]

12.4.4    Onion routing

Also in the late 1990s, a group of researchers at the U.S. Naval Research Laboratory (NRL) adapted the idea of using a Chaum mixing network to provide anonymous connections [20] in a system called onion routing [14, 15]. [21] The onion routing system is conceptually different from the JAP system. While onion routing works at the network layer and is independent from the application protocol in use, the JAP system is specifically designed for HTTP.

In onion routing, the term onion refers to a layered encrypted message, whereas the term onion router refers to a Chaum mix that acts as a node in a corresponding onion routing network. Instead of making TCP connections directly to a responding machine (the so-called responder ), an initiating application (the so-called initiator ) makes an anonymous connection through a sequence of onion routers. Contrary to normal routers, onion routers are connected by longstanding and permanent TCP connections. Although the technology is called onion routing, the routing that occurs does so at the application layer (and not at the Internet layer). More specifically, the system relies upon IP routing to route data through longstanding TCP connections. Therefore, although the series of onion routers in an anonymous connection is fixed for the lifetime of that connection, the route that data actually travels between individual onion routers is determined by the underlying IP network. Consequently, onion routing is conceptually similar to loose source routing with IP. Anonymous connections are multiplexed over longstanding connections. For any anonymous connection, the sequence of onion routers in a route is strictly defined at connection setup, and each onion router can only identify the previous and next hops along the route. Data passed along the anonymous connection appears different at each onion router, so data cannot be tracked en route and compromised onion routers cannot cooperate.

In onion routing, an application does not directly talk to a router nor to an onion router. Instead, there must be proxies that interface between the applications and the onion routing network. For example, to access a Web site through an onion routing network, one has to set the browser s HTTP proxy to an onion network entry point (a so-called application proxy). In fact, the initiator establishes a TCP connection to an application proxy. This proxy defines a (perhaps random) route through the onion routing network by constructing a layered data structure (an onion) and sending that onion through the network. Similar to a Chaum mixing network, each layer of the onion is encrypted with the public key of the intended onion and defines the next hop in the route. An onion s size is fixed, so each onion router adds some random padding data to replace the removed layer. The last onion router forwards data to the responder s application proxy, whose job is to pass data between the onion routing network and the responder. In addition to carrying the next hop information, each onion layer also contains seed material from which cryptographic keys will actually be derived (for encrypting or decrypting data sent forward or backward on the anonymous connection).

After sending the onion, the initiator s application proxy starts sending data through the established anonymous connection. As data moves through the anonymous connection, each onion router removes one layer of encryption, so it finally arrives as plain text. Obviously, the layering occurs in the reverse order for data moving backward from the receiver to the initiator. Stream ciphers are used for data encryption and decryption. Similar to the original idea of a Chaum mixing network, onion routers may also randomly reorder data items they receive before forwarding them (but preserve the order of data in each anonymous connection).

As mentioned previously and contrary to the original intent of a Chaum mixing network, the batching technique is out of the question for the support of interactive applications, such as HTTP. This means that coordinated observation of the network links connecting onion routers could eventually reveal an anonymous connection s route and leak the source and destination IP addresses accordingly. Therefore, it s important to ensure that the links between the onion routers can t be simultaneously eavesdropped upon. The easiest way to achieve this is to put onion routers on different network segments in different buildings with different administrators ”ones who would be unlikely to collude. Also note that by layering cryptographic operations in the way described above, an advantage is gained over conventional-style link layer encryption. Even though the total cryptographic overhead for passing data is the same as for link layer encryption, the protection is better. In link layer encryption, the chain is as strong as the weakest link, and one compromised node can reveal everything. In onion routing, however, the chain is as strong as its strongest link, and one honest onion router is enough to maintain the anonymity of the connection. Even if link layer encryption were used together with end-to-end encryption, compromised nodes could still cooperate to reveal route information. This is not possible in an onion routing network, since data always appears differently to each onion router.

For TCP-based application protocols that are proxy aware, such as HTTP, Telnet, and SMTP, there are application proxies for Sun Solaris. Interestingly, for certain application protocols that are not proxy aware, most notably rlogin, it has been possible to design interface proxies as well. In either case, the best protection results from having a connection between an application proxy and an onion router that is trusted one way or another. For example, one possibility is to place an onion router on the firewall of a corporate intranet. In this case, the onion router would serve as an interface between the machines behind the firewall and the external network (most notably the Internet).

In summary, onion routing is a technology that deserves further study and wider deployment. Unfortunately, the onion router prototype network went off-line in January 2000, so it is not likely that we will see the technology widely deployed on the Internet or WWW anytime soon. Further information about onion routing and the onion router prototype network is available at the onion routing home page. [22]

12.4.5    Freedom network

More recently, a Canadian company called Zero-Knowledge Systems [23] has developed and is marketing a technology that is conceptually similar to onion routing. In fact, Zero-Knowledge Systems has coined the term Freedom network to refer to its Chaum mixing network, and the term Freedom server to refer to a Chaum mix. The Freedom Network is designed so that each packet is sent through at least three separate Freedom servers, each one operated by a different orgnaizations. It will be interesting to see how successful the Freedom Network will be deployed on the global Internet or WWW.

[13] Most existing HTTP proxy servers (e.g., Apache) provide support for nested URLs.

[14] http://www.anonymizer.com

[15] http://www.idzap.com

[16] http://anon.inf.tu-dresden.de

[17] The term jondo is pronounced ˜ ˜John Doe. It refers to the image of a faceless participant of the system.

[18] Note, however, that another bottleneck of the system is the communication that must take place. This bottleneck cannot be resolved using a compiled language.

[19] http://www.research.att.com/projects/crowds

[20] Anonymous connections are similar to TCP connections, but they are also resistant against passive and active attacks (including traffic analysis). Anonymous connections are bidirectional, have small latency, and can be used anywhere a TCP connection can be used. Note that a connection may be anonymous, although communication need not be (e.g., if the data stream is not encrypted).

[21] Note that the onion routing system is conceptually similar to the PipeNet proposal that was posted by Wei Dai to the Cypherpunks mailing list in February 1995. Contrary to the onion routing system, however, the PipeNet proposal has not been implemented so far.

[22] http://www.onion-router.net

[23] http://www.zeroknowledge.com




Security Technologies for the World Wide Web
Security Technologies for the World Wide Web, Second Edition
ISBN: 1580533485
EAN: 2147483647
Year: 2003
Pages: 142
Authors: Rolf Oppliger

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net