Apt over Tor

Debian users can now download packages and updates over the Tor network—a feature that, among other benefits, guards against attackers attempting to locate machines with unpatched security vulnerabilities. Developers have yet to integrate Tor support into every package-management tool, much less push for the service to become the default, but in light of the advantages that using Tor as a transport provides, it would not be surprising to see further integration work in the months to come.

The principle rationale for employing Tor for package and update downloads is straightforward. If an eavesdropper observes an HTTP request for an update from a Debian mirror—specifically, an update that patches a vulnerability—coming from a particular IP address, then they know with degree of certainty that the machine at that IP is currently unpatched, and they can attempt an attack before the update is installed. There may be only a short window of time to capitalize on this knowledge, but if there are a lot of updates being downloaded, it may still be plenty.

At DebConf15, Tor's Jacob Appelbaum made the case that this sort of attack was grounds for always downloading updates over HTTPS. But Richard Hartmann pointed out that even a TLS-protected download could leak enough information for an attacker to determine that a specific update is being downloaded. For one thing, the updates are publicly accessible, so the attacker can easily learn the download sizes of any updates of interest. Furthermore, security updates are hosted at a different server, security.debian.org, so all downloads coming from that address are potential red flags for observant attackers.

Hartmann proposed setting up a Tor hidden service to make the Debian archive accessible through Tor. Peter Palfrader then took him up on the idea and established such a service at http://vwakviie2ienjx6t.onion/. Hartmann's post reports that he successfully used the torify wrapper script to access the service over a SOCKS proxy using the standard Apt. He also noted that several Debian project members had discussed plans to Tor-enable not just Apt, but the Debian bug-reporting tools, package-upload tools, and other components of the package-management lifecycle.

Hartmann's usage of torify to access the service seemed to puzzle some commenters at his blog, since it amounted to manually tunneling a normal Apt connection through SOCKS. If done regularly, that approach could become tiresome, and there was already a tool available that could automatically direct all Apt operations over a Tor circuit.

That somewhat more sophisticated solution is Tim Retout's apt-transport-tor package. First started in mid-2014, apt-transport-tor is a pluggable transport layer for Apt; one needs only to install the package and change any URLs in a sources.list to use the prefix tor+http:// or tor+https:// .

Perhaps it is unknown to some, but Apt has supported pluggable transports since the 0.7.0 release in January 2007. The framework was first used to implement HTTPS support (with the Apt team maintaining the apt-transport-https package). The first transport from outside developers was implemented in the apt-transport-debtorrent package added with Apt 0.7.25 in December 2009. There are a handful of other apt-transport options, including one for retrieving packages from Amazon S3 storage and one for accessing Spacewalk configuration servers. In January 2016, Petter Reinholdtsen posted instructions on his blog for how to configure Apt to use Palfrader's hidden service. Currently, only Debian "Jessie" and newer (i.e., the unstable or experimental suites) are supported.

Strictly speaking, the hidden-service site is not required in order to benefit from using Tor as a transport mechanism. A user could connect to a Debian mirror over a Tor circuit and the user's endpoint would be effectively protected against discovery by attackers. But traffic between the Tor exit node and the mirror could still be monitored, and a powerful attacker could, theoretically, use timing or other side-channel attacks to infer that an update of interest was being downloaded.

The hidden service enables package downloads to be performed entirely within the Tor network, eliminating that risk. In his blog post, Reinholdtsen observed that there may be other benefits to using Tor to fetch package updates, such as the fact that Apt will periodically generate Tor traffic from the machine by fetching package updates and checking for update information, thus making it incrementally more difficult for an attacker to determine that the user is doing something else with Tor (e.g., accessing a censored web site).

Reinholdtsen also pointed out that there are several Apt-related tools that currently do not work with the Tor transport mechanism—most notably apt-file, which is used to find the available packages that include a given filename. The apt-file package in Debian experimental, however, has been updated to support apt-transport-tor.

Hartmann also posted a follow-up where he addressed some common questions. Perhaps the biggest concern moving forward is that using Apt does leak some potentially private information about the user's machine: the architecture, Debian release, software suite, and the names and versions of packages are all transmitted to the server. That data is required for Apt to fetch the required package files and updates, which means that users who are particularly concerned about maintaining privacy will want to employ the Tor transport and specify HTTPS. Accessing the hidden-service endpoint of the Debian mirror and not simply tunneling the traffic over Tor may provide additional protections against the inference of what is being downloaded if there are detectable differences in the size of updates for different suites or architectures.

But the Tor hidden service set up by Palfrader remains experimental, and converting it to a stable, permanent offering may take some time—as Hartmann noted in his second post, the hidden-service endpoint will need to be load-balanced in order to handle a significant number of users. The project has gained a following within Debian, though. Following Palfrader's mirror, Jonathan "noodles" McDowell added a hidden-service endpoint to his own Debian mirror.

Subsequently, a project page was set up on the Debian wiki, which notes other services that are candidates for "Torification" and the infrastructure tasks to go along with them—such as tools to let the Debian System Administration team manage the hidden-service key pairs.

It is too early to predict how or when Debian will make Tor hidden-service access to core services a standard feature but, if it does so, Debian would be the first major distribution to implement that level of Tor support. As Reinholdtsen pointed out in his post, the FreedomBox distribution already uses apt-transport-tor if Tor support is enabled in the configuration. But FreedomBox is considerably more limited in its scope. A successful implementation of Tor services by Debian would, no doubt, encourage several other distributions to take a hard look at providing similar features to their users.