Client life cycle

Every peer-to-peer system has to deal with the possibility that clients will disappear unexpectedly, but senescence is actually assumed for Red Rover clients. Use it long enough and, just as with tax cheating, they'll probably catch up with you. In other words, the client's available IPs will eventually all be blocked by the authorities.

The predominant way nations block web sites is by IP address. This generally means all four octets are blocked, since C-class blocking (blocking any of the possibilities in the fourth octet of the IP address)

The nice thing about a personal web server is that when a user logs on to a dial-up account, the user will most likely be assigned a fourth octet different from the one she had in previous sessions. With most ISPs, odds are good of getting a different third octet as well. This means that a client can sustain a great number of blocks before becoming useless, and, depending on the government's methods (and human workload), many events are likely to evade any notice whatsoever. But whenever the adversary is successful in completely blocking a Red Rover client's accessible IP addresses, that's the end of that client's usefulness - at least until the user switches ISPs. (Hopefully she'll choose a new ISP that hasn't been blocked due to detection of another Red Rover client.) Some users can make their clients more mobile, and therefore harder to detect, by subscribing to a variety of free dial-up services.

A fact in our favor is that it is considered extremely unlikely that countries will ever massively block the largest ISPs. A great deal of damage to both commerce and communication would result from a country blocking a huge provider like, for example, America Online, which controls nearly a quarter of the American dial-up market. This means that even after many years of blocking Red Rovers, there will still always be virgin IPs for them. Or so we hope.

The Red Rover strategy depends upon a dynamic population. On one level, each user can stay active if she has access to abundant, constantly changing IP addresses. And at another level, Red Rover clients, after they become useless or discontinued, are refreshed by new users, compounding the frustration of would-be blockers.

The client will be distributed freely at software archives and partner web sites after its release, and will operate without user maintenance. A web site (see Section 10.4) is already live to provide updates and news about the strategy, as well as a downloadable client.

10.3 Putting low-tech "weaknesses" into perspective

Red Rover creates a high-tech relationship between the hub and the client (using SL and strong encryption) and a low-tech relationship between the client and the subscriber. Accordingly, this latter relationship is inherently vulnerable to security-related difficulties. Since we receive many questions challenging the viability of Red Rover, we present below in dialogue form our responses to some of these questions in the hope of putting these security "weaknesses" into perspective.

Skeptic:

I understand that the subscriber could change subscription times and addresses during a Red Rover visit. But how would anyone initially subscribe? If subscription is done online or to an email site, nothing would prevent those sites from being blocked. The prospective subscriber may even be at risk for trying to subscribe.

Red Rover:

True, the low-tech relationship between Red Rover and the client means that Red Rover must leave many of the steps of the strategy to the subscriber. As we've said above, another channel such as a letter or phone call (not web or email communication) will eventually be necessary to initiate contact since the Red Rover site and sites which mirror it will inevitably be victims of blocking. But this requirement is no different than other modern security systems. SSL depends on the user downloading a browser from a trusted location; digital signatures require out-of-band techniques for a certificate authority to verify the person requesting the digital signature.

This is not a weakness; it is a strength. By permitting a diversity of solutions on the part of the subscribers, we make it much harder for a government to stop subscription traffic. It also lets the user determine the solution ingredients she believes are safest for her, whether public key cryptography (legal, for now, in many blocking countries), intercession by friends who are living in or visiting countries where subscribing would not be risky, proxy-served requests to forward email to organizations likely to cooperate, etc.

We are confident that word of mouth and other means will spread the news of the availability of Red Rover. It is up to the subscriber, though, to first offer her invitation to crash the censorship barrier. For many, subscribing may not be worth the risk. But for every subscriber who gets information from Red Rover, word of mouth can also help hundreds to learn of the content.

If this response is not as systematic as desired, remember that prospective subscribers face vastly different risks based on their country, profession, technical background, criminal history, dependents, and other factors. Where a problem is not recursively enumerable, the best solution to it will rarely be an algorithm. A variety of subscription opportunities, combined with non-patterned choices by each subscriber, leads to the same kind of protection that encryption offers in computing: Both benefit from increased entropy.

Skeptic:

What is to stop a government from cracking the client and cloning their own application to entrap subscribers or send altered information?

Red Rover:

Red Rover has to address this problem at both the high-tech and low-tech levels. I can't cover all strategies available to combat counterfeiting, but I can lay out what we've accomplished in our design.

At the high-tech level, we have to make sure the hub can't be spoofed, that the client knows if some other source is sending data and pretending to be the hub. This is a problem any secure distributed system must address, and a number of successful peer-to-peer systems have already led the way in solving this problem. Red Rover can adopt one of these solutions for the relationship between the hub and clients. This aspect of Red Rover does not need to be novel.

Addressing this question for the low-tech relationship is far more interesting. An alert subscriber will know, to the second, what time she is to receive email notifications. This information is sent and recorded using an SSL-like solution, so if that time (and perhaps other clues) isn't present on the email, the subscriber will know to ignore any IP addresses encoded in it.

Skeptic:

Ah, but what stops the government from intercepting the IP list, altering it to reflect different IP addresses, and then forwarding it to the subscriber? After all, you don't use standard encryption and digest techniques to secure the list.

Red Rover:

First, we have taken many precautions to make it hard for surveillance personnel to actually notice or suspect the email containing the IP list. Second, remember that we told the subscribers to choose web-based email accounts outside the boundaries of the censoring country. If the email is waiting at a web-based site in the United States, the censoring government would have to intercept a message during the subscriber's download, determine that it contained a Red Rover IP address (which we've encoded in a low-tech manner to make it hard to recognize), substitute their own encoded IP address, and finish delivering the message to the subscriber. All this would have to be done in the amount of time it takes for mail to download, so as not to make the subscriber suspicious. It would be statistically incredible to expect such an event to occur.

Skeptic:

But the government could hack the web-based mail site and change the email content without the subscriber knowing. So there wouldn't be any delay.

Red Rover:

Even if this happened, the government wouldn't know when to expect the email to arrive, since this information was passed from the subscriber to the client via SSL. And if the government examined and counterfeited every unread email waiting for the subscriber, the subscriber would know from our instructions that any email which is not received

"immediately" (in some sense based on experience) should be distrusted. It is in the subscriber's interest to be prompt in retrieving the web pages from the clients anyway, since the longer the delay, the greater the chance that the client's IP address will become inactive.

Still, stagnant IP lists are far more likely to be useless than dangerous.

Skeptic:

Red Rover:

This has been under some debate. Options always include adding file server functions or IRC capability to entice users into spending a lot of time at the sponsor's site. Another thought was letting users add their own, client- specific customized page to the HTML offering, one which would appear last so as not to interfere with the often slow downloading of the primary content by subscribers in countries with stiff Internet and phone rates and slow modems. This customized page could be pictures of their dog, editorials, or, sadly but perhaps crucially, advertising. Companies could even pay Red Rover users to post their ads, an obvious incentive. But many team members are rightfully concerned that if Red Rover becomes viewed as a mercantile tool, it would repel both subscribers and client users. These discussions continue.

Skeptic:

Where does the name " Red Rover" come from?

Red Rover:

Red Rover is a playground game analogous to the strategy we adopted for our anti-censorship system. Children form two equal lines, facing each other. One side invites an attacker from the other, yelling to the opposing line: "Red Rover, Red Rover, send Lena right over." Lena then runs at full speed at the line of children who issued the challenge, and her goal is to break through the barrier of joined arms and cut the line. If Lena breaks through, she takes a child back with her to her line; if she fails, she joins that line. The two sides alternate challenges until one of the lines is completely absorbed by the other.

It is a game, ultimately, with no losers. Except, of course, the kid who stayed too rigid when Lena rammed him and ended up with a dislocated shoulder.

We hope Red Rover leads to similar results.

10.4 Acknowledgments

The author is grateful to the following individuals for discussions and feedback on Red Rover: Erich Moechel, Gus Hosein, Richard Long, Sergei Smirnov, Andrey Kuvshinov, Lance Cottrell, Otmar Lendl, Roger Dingledine, David Molnar, and two anonymous reviewers. All errors are the author's.

Red Rover was unveiled in April 2000 at Outlook on Freedom, Moscow, sponsored by the Human Rights Organization (Russia) and the National Press Institute, in a talk entitled "A Functional Strategy for an Online Anti-Blocking Remedy," delivered by the author. Red Rover's current partners include Anonymizer, Free Haven, Quintessenz, and VIP Reference. Updates about production progress and contact information about Red Rover will be posted at http://redrover.org/.

Chapter 11. Publius

Marc Waldman, Lorrie Faith Cranor, and Avi Rubin, AT&T Labs-Research

Publius is a web-based publishing system that resists censorship and tampering. A file published with Publius is replicated across many servers, making it very hard for any individual or organized group to destroy the document. Distributing the document also provides resistance to so-called distributed denial of service (DDoS) attacks, which have been used in highly publicized incidents to make a resource unavailable. Another key feature of Publius is that it allows an individual to publish a document without providing information that links the document to any particular computer.

Therefore, the publisher of a document can remain anonymous.

Publius has been designed with ease of access for end users in mind. HTML pages, images, or any other type of file can be published with the system. Documents published with Publius can be read with a standard web browser in combination with an HTTP proxy that can run locally or remotely.

Files published with Publius are assigned a URL that can be entered into a web browser or embedded in a hyperlink.

The current architecture of the World Wide Web does not lend itself easily to censorship-resistant, anonymous publication. Published documents have a URL that can be traced back to a specific Internet host and usually a specific file owner. However, there are many reasons why someone might wish to publish something anonymously. Among the nobler of these reasons is political dissent or

"whistleblowing." It is for these reasons that we designed Publius. Chapter 12 covers Free Haven, a project with some similarities, and provides more background on anonymity.

Anonymous publishing played an important role in the early history of the United States. James Madison, Alexander Hamilton, and John Jay collectively wrote the Federalist Papers under the pen name Publius. This collection of 85 articles, published pseudonymously in New York State newspapers from October 1787 through May 1788, was influential in convincing New York voters to ratify the proposed United States Constitution. It is from these distinguished authors that our system gets its name.

Like many of the other systems in this book, Publius is seen from the outside as a unified system that works as a monolithic service, not as a set of individual Internet hosts. However, Publius consists of a set of servers that host content. These servers are collectively referred to as Publius Servers. The Publius Servers are independently owned and operated by volunteers located throughout the world.

The system resists attack because Publius as a whole is robust enough to continue serving files even when many of the hosts go offline.

Publius uses two main pieces of software. The first is the server software, which runs on every Publius server. The second piece of software is the client software. This software consists of a special HTTP proxy that interfaces with a web browser and allows an individual to publish and retrieve files. In this chapter we use the terms proxy and client software interchangeably, as they both refer to the HTTP proxy. In order to use Publius an individual runs the proxy on their computer or connects to a proxy running on someone else's computer.