relays

The Tor Cloud images for all the eight regions have been updated with a minor fix in the rc.local script. In addition, all private bridge images now include Obfsproxy. You will not need to start a new instance if you are already running a Tor Cloud instance with Ubuntu Precise.

The Tor Cloud images for all the seven regions have been updated to include the latest cloud image for stable Ubuntu release 12.04.1 LTS (Precise Pangolin). These new images are available on the Tor Cloud website. You will not need to start a new instance you are already running a Tor Cloud instance with Ubuntu Precise.

The Tor Cloud images for all the seven regions have been updated to fix a bug found in the unattended-upgrades configuration. The normal bridge images have also been updated to include obfsproxy, which attempts to help users circumvent censorship by transforming the Tor traffic between the client and the bridge.

If you are already running a Tor Cloud bridge, you will need to either manually update your image, or set up a new Tor Cloud bridge and terminate the old one. If you decide not to take action, your image will fail to upgrade Tor correctly and will not be running as a bridge.

If you just want to fix the bug in the unattended-upgrades configuration, do the following; log on with SSH and edit /etc/apt/apt.conf.d/50unattended-upgrades to say precise instead of lucid.

The Tor Cloud images for all the seven regions have been updated to include the latest cloud image for stable Ubuntu release 12.04.1 LTS (Precise Pangolin). These new images are available on the Tor Cloud website.

The new images include Tor's new GPG key, uses apt-get instead of aptitude, and also includes the deb.torproject.org-keyring package (#6776).

If you are already running a Tor Cloud bridge, you will need to either manually update your image, or set up a new Tor Cloud bridge and terminate the old one. If you decide not to take action, your image will fail to upgrade Tor correctly and will not be running as a bridge. To manually update your image; log on with SSH, and follow the instructions to add the new GPG key, upgrade Tor, and install the deb.torproject.org-keyring package.

The Tor Cloud images for all the seven regions have been updated to include the latest cloud image for stable Ubuntu release 10.04 LTS (Lucid Lynx). These new images are available on the Tor Cloud website.

The new images include a fix to allow Tor to upgrade automatically without requiring user intervention (#6511).

If you are already running a Tor Cloud bridge, you will need to either manually update your image, or set up a new Tor Cloud bridge and terminate the old one. If you decide not to take action, your image will fail to upgrade Tor correctly and will not be running as a bridge.

To manually update your image, do the following:

0. Log on with SSH
1. Open /etc/apt/apt.conf.d/50unattended-upgrades
2. Add the line: Dpkg::Options { --force-confold; }
3. Save and exit

The Tor network relies on volunteers to donate bandwidth. The more people who run Tor as a bridge or a relay, the faster and safer the network becomes. Tactical Tech created a video to encourage you to join the Tor Network. The video, and information about how you can set up a bridge or a relay, can be found on https://www.torproject.org/relays. If you want to help us translate the video into your language, let us know!

The full HD video can be found here: https://media.torproject.org/video/2012-03-04-BuildingBridges-HD.ogv

Tor 0.2.3.7-alpha fixes a crash bug in 0.2.3.6-alpha introduced by the new v3 handshake. It also resolves yet another bridge address enumeration issue.

All packages are updated, with the exception of the OS X PPC packages. The build machine is down and packages will be built as soon as it is back online.

https://www.torproject.org/download

Changes in version 0.2.3.7-alpha - 2011-10-30
Major bugfixes:

• If we mark an OR connection for close based on a cell we process,
  don't process any further cells on it. We already avoid further
  reads on marked-for-close connections, but now we also discard the
  cells we'd already read. Fixes bug 4299; bugfix on 0.2.0.10-alpha,
  which was the first version where we might mark a connection for
  close based on processing a cell on it.
• Fix a double-free bug that would occur when we received an invalid
  certificate in a CERT cell in the new v3 handshake. Fixes bug 4343;
  bugfix on 0.2.3.6-alpha.
• Bridges no longer include their address in NETINFO cells on outgoing
  OR connections, to allow them to blend in better with clients.
  Removes another avenue for enumerating bridges. Reported by
  "troll_un". Fixes bug 4348; bugfix on 0.2.0.10-alpha, when NETINFO
  cells were introduced.

Trivial fixes:

• Fixed a typo in a hibernation-related log message. Fixes bug 4331;
  bugfix on 0.2.2.23-alpha; found by "tmpname0901".

The Tor network is run by volunteers, and for the most part is entirely independent of the software development effort led by The Tor Project, Inc. While The Tor Project, Inc is a 501(c)3 non-profit that is happy to take donations to create more and better software, up until recently there was no way for you to fund deployment of more relays to improve network capacity and performance, aside from running those relays yourself.

We're happy to announce that both Noisebridge and TorServers.net are now able to take donations directly for the purpose of running high capacity Tor exit nodes.

Noisebridge is a US 501(c)3 non-profit, which means that for US citizens, donations are tax deductible. Torservers.net is a German non-profit organization whose donations are tax deductible for German citizens (and also potentially for citizens of other EU member states).

What are the pluses and minuses of donating as opposed to running your own relay? Glad you asked!

While it is relatively easy and risk-free to run a middle relay or a bridge, running an exit can be tough. You have to seek out a friendly ISP, explain Tor to them, and then navigate a laundry list of Internet bureaucracies to ensure that when abuse happens, the burden of answering complaints falls upon you and not your ISP.

These barriers are all made easier the larger your budget is. On top of this, like most things, bandwidth is cheaper in bulk. But not just Costco cheaper: exponential-growth cheaper, all the way up into the gigabit range (and perhaps beyond, but no one has run a Tor node on anything faster).

At these scales, large exit nodes can pay as little as $1/mo per dedicated megabit/second. Sometimes less. This means that adding $30/mo to the hosting budget of a large exit node can buy almost 40 times more full-duplex dedicated bandwidth than a similarly priced business upgrade to your home ADSL line would buy, and about 50 times more bandwidth than Amazon EC2 instances at the entry-level price of $0.08 per half-duplex gigabyte, not counting CPU costs. (Bridge economics in terms of IP address space availability might still favor Amazon EC2, but that is a different discussion).

The downside to donation is that network centralization can lead to a more fragile and a more observable network. If these nodes fail, the network will definitely feel the performance loss. In terms of observability, fewer nodes also means that fewer points of surveillance are required to deanonymize users (though some argue that more users will make such surveillance less reliable, no one has yet rigorously quantified that result against actual attacks).

Therefore, if you are able to run a high capacity relay or exit yourself (or have access to cheap/free/unused bandwidth at your work/school), running your own relay is definitely preferred. If you are part of the Tor community and want to accept donations, we'd love to add you to our recommended donor list. Please join us on the tor-relays mailing list to discuss node configuration and setup.

However, if configuring and maintaining a high capacity relay is not for you, donating a portion of the monthly hosting budgets of either of these organizations is an excellent way to support anonymity, privacy, and censorship circumvention for very large numbers of people.

The current state of affairs in Egypt looks quite bleak for people using Vodafone, Orange, TE Data, and other well-known service providers. It is reported that each of those companies was ordered by the Egyptian government to turn down their internet services. The nature of the order and its legality is of course very unclear at this time. What is known is that nearly in perfect unison many Egyptian ISPs turned down their BGP route announcements to countries outside of Egypt and from what we've been able to gather they're also not peering with each other. The cables connecting (FLAG and SEABONE) Egypt to the world are still physically intact.

The impact of de-peering is significant; even if someone is able to get packets directly to the edge routers of TE Data or another ISP, no response will be forthcoming. Renesys, RIPE, and BGPmon have fantastic technical details for those without access to an active BGP router.

At this point it is also well-known that the ISP Noor has been up through the entire event. With access to systems inside of Egypt, we have discovered that it appears to be entirely unfiltered - Tor works perfectly, controversial websites are not blocked, and it is even quite fast compared to our systems on other Egyptian networks. As of very late last night, systems from Noor were still unable to reach systems on TE Data or other networks in Egypt. Early this morning it appears that another ISP, Etisalat (AS36992), returned to the Internet (via nileonline.palermo7.pal.seabone.net) and we're working with contacts in Egypt to test any possible filtering and to ensure that Tor is functional on their network.

In our tests of the TE Data network before it disconnected, we found very heavy handed but sloppy filtering. Tests of popular websites revealed that TE Data filtered based on IP blocklists, they did not tamper with DNS queries, they did not trigger TCP resets on keywords, nor did they attempt to perform any kind of Man-In-The-Middle attacks on SSL or SSH connections. While it is possible that TE Data may have layer seven filtering or Deep Packet Inspection capabilities, it does not appear to have used any advanced filtering methods.

While the seemingly unfiltered nature of Noor's network is a positive development and sharply contrasts with the heavy filtering of TE Data's network, we have no methods for discovering data retention policies or wiretapping capabilities of any of the available networks in Egypt. We urge all people in Egypt to consider that any ISP may log data and depending on political outcomes, it may not be favorable to have easy to trace records of your online activities.

Many Egyptians are also using dial up services that route through the Egyptian controlled state telecommunications systems. While on the face this seems safe and it may very well be safer than a known filtered or probably wiretapped network, it's certainly not outside of the capabilities of the Egyptian authorities to decode or analyse these kinds of communications. We urge people who are using dial up systems or leased lines, VSAT or even BGAN connections to be cautious. The nature of any internet connection has a variable difficulty for monitoring but it is by no means impossible. That's why we're working so hard on Tor because the world needs software for traffic analysis resistance; the internet doesn't have this for free and certainly not in a country with a highly centralized internet architecture.

There is a serious trade off to be made by users in hostile network environments with major political instability: Tor usage is possibly detectable with a skilled adversary. Connections made with questionable "privacy" or "security" proxy services are certainly easier than detecting Tor because of their static nature. The same is true of VPN services: all of these things are probably detectable with the right understanding and the proper equipment. It goes without saying that entirely unprotected connections to known unfavorable sites or services is detectable and well within the reach of the Egyptian network operators.

Please understand that while we make no promises, we believe that Tor is currently the best option for people in this situation. It's what we use when we're in Egypt and it's what we think will serve people the best in Egypt when they have a network connection to the rest of the internet.

The number of users in Egypt in the last week has skyrocketed:

The number of bridges run around the world has increased remarkably:

Most impressively, the number of fully public Tor relays has increased:

It appears that the Tor network itself has gained bandwidth capacity and geographical scope thanks to people concerned with the situation in Egypt. If you'd like to get involved, we'd love it if you could help by running a Tor relay or a Tor bridge.

Update: As of late January 30th, most of Egypt's BGP routes for residential access has been pulled from the Internet.