Security

GUADEC: Imagining Tor built-in to GNOME

Jacob Appelbaum of the Tor project delivered the opening keynote at GUADEC 2012 in A Coruña, Spain, tackling better anonymity on the desktop. Appelbaum outlined the design of Tor, discussed statistics about the Tor network, and spoke about its future. One of his more interesting suggestions was that GNOME and other user environments could build in Tor support as a standard networking option. That would make Tor easier to use, and would provide the user with several peripheral benefits.

Tor, anonymity, and you

Tor is widely known these days, but Appelbaum gave a brief overview of the system's protocol and network design, highlighting some frequently-overlooked facets of the project. First, he said, Tor is larger than most people realize. It employs more than a dozen developers and receives additional help from around 100 volunteer coders. The developer-power is critical to Tor's success, he said, as almost any bug in the code turns into a security bug. At a given moment, it averages around 3,000 active relays, 400,000 users, and handles 1.2 GiB/s of traffic. Tor is a non-profit organization, and may be unique in that it receives funding from both the Electronic Frontier Foundation (EFF) and the U.S. Department of Defense.

Tor's mission is often misunderstood, too. Although it provides a means of securing communication channels, its primary function is as an anonymity tool. Anonymity comes in a variety of types, he said, but the core idea is "trying to be free from surveillance and censorship." Tor gives you one thing off the bat, he said: an anonymous IP address. Everything else is your choice from there. The WiFi at the venue blocked SSH connections, Appelbaum said, so he needed to tunnel over Tor to connect to his servers. That represents one type of anonymity: freedom from network administrators inspecting your traffic.

A different type of anonymity might be signing in to GMail over Tor in order to hide your geographic location. In that case, you still authenticate to Google, so the company knows who you are, but you do not have to reveal where you are simultaneously. The US government asserts that individuals have no reasonable expectation of privacy when voluntarily interacting with a business, including increasingly common web tracking techniques. Appelbaum showed an EFF diagram illustrating privacy risks from numerous angles, including "black hat" hackers, system administrators, lawyers, law enforcement, and even government agencies.

For each of those potential privacy foes, there are times when an activity that would be innocuous otherwise becomes risky because someone is monitoring your communication. The question for a project like GNOME, he said, is "how free is your desktop if you're not able to freely interact with others?" Although some assume that online anonymity is only the concern of "bad people," he said, that is "a bit of a white privilege issue." Censorship is quite widespread and in practice it affects "good" people as much as anyone else, a fact he illustrated with a collection of error page screenshots from government and private networks that block access to Tor project sites.

The Tor project's solution is to build a network that offers "privacy by design" rather than by policy. Policies are hard to enforce and are subject to human error and bad actors. Tor makes network connections private in a number of ways. Once every hour, the project's trusted directory relays re-map the entire network. Clients retrieve the latest version of the map (thus limiting the potential time window of a widespread attack). Once every ten minutes, clients select a new route through the Tor network for their traffic channels (thus helping to protect them against analysis from within the network). Each route through the Tor network is encrypted separately between each pair of nodes along the route (so that the first node knows the originating address but not the destination, the exit node knows the destination but not the origin, and the intermediary nodes know neither).

A censor could attempt to block all access to Tor by retrieving the network directory and blocking the entry points by IP address, so the project also runs hidden "bridge relays" that are unlisted. Users can fetch a short list of bridge relays via email or through a CAPTCHA-protected web form. The email method requires using an address from gmail.com or yahoo.com, which the project says helps make it more difficult for attackers to discover a significant number of bridges.

Tor statistics

Tor's pervasive anonymity makes it difficult to profile or monitor the network as a whole, Appelbaum said, but the project uses data mining to take snapshots and keep an eye on performance. Tor's total bandwidth and latency have improved significantly since 2010, he said. Back then, the median time to complete a request was approximately 25 seconds. In 2012, it is down to 2.5 seconds. Total maximum bandwidth has increased in the same time period from 500 to 2500 MiB/s.

The primary reason for the increase has been a significant uptick in the number of volunteers serving as Tor nodes — a change that has corresponded with the "Arab spring" upheavals in the Middle East. Based on analysis of the Tor network, the events in the Middle East have been followed quickly by a spike in new participants, and the network does not taper back down to its pre-spike size.

Which is not to say that there are never incidents of downticks in the Tor network. The project can detect sudden acts of censorship by examining metrics of the Tor network as well as traffic to its own domain. For example, in February 2012, Kazakhstan deployed protocol inspection and began blocking access to Tor. It was without doubt an expensive operation, Appelbaum said, even though the total number of users in the country was around 1200.

Nevertheless, the project is actively working on ways to circumvent such censorship actions. There is already an "obfuscated bridge" option, in which the bridge relay and the Tor client fake what appears to be a standard Firefox-to-Apache handshake. There are other options still in development, including steganographic handshakes. But outright censorship is probably not the wave of the future, Appelbaum said. The government in Syria has learned that it is more effective to watch who accesses sites that it finds objectionable than it is to block access to them across the board, and the U.S. government prefers to use U.S. law to suppress people over any purely technological measures.

The onion gnome?

The Tor network is healthy, Appelbaum said, but the tools to access it still need some work. Tor's own Vidalia application may have a dreadful UI, he said, but it is much better than it was five years ago. He highlighted several excellent projects, such as the Pidgin IM client (which has built-in support for Tor) and the TorBirdy extension for Mozilla Thunderbird, but argued that it would be better for the user if the functionality to use Tor was built into the operating system itself. After all, that option would require solving the anonymity problem once, rather than 50 times.

The option for GNOME would be to add support for Tor as a transport in Network Manager, much like VPNs are offered today. It might also be useful if an application could request a "private mode," which would activate the Tor connection and otherwise sandbox the process (both to protect against malicious content coming in, and to prevent the application from intentionally or accidentally leaking information about the local system over the connection). This would take some work to implement, he said, because Network Manager today does not "fail closed" — a fact that can be illustrated by its current VPN support. Applications using the VPN connection continue to function even when the VPN goes down, because Network Manager simply routes traffic through the existing network.

Built-in Tor functionality would come in handy in other ways, too, he said, such as with GNOME's "guest sessions." As it is now, anything a guest does while running in a guest session can be traced back to the computer — and the user needs to ask if that is something that he or she wants. It would be better if Tor automatically anonymized guest sessions for the user's protection.

He mentioned several other changes that GNOME could make to offer a more complete privacy-respecting environment for its users. One was allowing the user control over the Zeitgeist activity logger, which he said amounted to spyware if the user has not agreed to it. At the very least it should be encrypted and subject to user control. Zeitgeist developer Seif Lotfy is currently working on a "privacy panel" for GNOME, which Appelbaum suggested would be a good fit.

Appelbaum surveyed friends and colleagues about what to tell GUADEC attendees, and they provided three other suggestions. First, implement off-the-record (OTR) messaging in Empathy. Second, implement a fake-MAC-address generator, to keep a machine's real MAC address safe from monitoring on guest networks. Third, implement a Tor-based file transfer method in Telepathy.

Despite the list of feature requests, Appelbaum had plenty of good things to say about GNOME as well, in part because it has formed the basis for several good outside projects that offer anonymity and privacy tools. One example is the Tails live CD distribution, which is configured to use Tor for Internet connections out-of-the-box.

It remains to be seen whether GNOME will actually implement Tor as a Network Manager transport — it is clearly too late for inclusion in the 3.6 release currently in development. But over the course of the week, several GUADEC attendees were still discussing the idea, and it was mentioned in numerous personal blog posts about the event on Planet GNOME. Appelbaum certainly succeeded in raising the question of built-in privacy with the crowd, which could impact GNOME (and other open source projects) further down the line.

[The author would like to thank the GNOME Foundation for travel assistance to A Coruña for GUADEC.]

Comments (4 posted)

Brief items

Security quotes of the week

Comments (none posted)

Walsh: SELinux Apache Security Study

Comments (none posted)

New vulnerabilities

auditlog-keeper: information disclosure

Comments (none posted)

bind-dyndb-ldap: named assertion failure

Comments (none posted)

dhcp: denial of service

Comments (none posted)

ecryptfs-utils: privilege escalation

Comments (none posted)

fckeditor: cross-site scripting

Comments (none posted)

globus-gridftp-server: privilege escalation

Comments (none posted)

glpi: multiple vulnerabilities

Comments (none posted)

graphicsmagick: unspecified vulnerability

Comments (none posted)

icinga: unintended database access

Comments (none posted)

kernel: information disclosure

Comments (none posted)

libreoffice: code execution

Comments (none posted)

moodle: many vulnerabilites

Comments (none posted)

python-django: multiple vulnerabilities

Comments (none posted)

sudo: symlink attack

Comments (none posted)

xen: denial of service

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>