Tor at the Heart: apt-transport-tor and Debian onions
During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom.
apt-transport-tor and Debian onions
Did you know that when you're using Debian, you can configure your operating system package installs and updates to route through Tor?
Doing updates via Tor provides some really compelling security properties. One of the big benefits is that an attacker can't target you for a malicious update: even if they manage to steal some package signing keys and break into the update server and replace packages, they still can't tell that it's you asking for the update. So if they want to be sure you get the malicious update, they're forced to attack everybody who updates, which means a really noisy attack that is much more likely to get noticed. This anonymity goal is one of the main reasons that Tor Browser does its updates over Tor as well.
Another big feature of updating via Tor is that the package repository, or somebody watching it, can't track what programs you've installed. Similarly, somebody spying on your Internet connection will have a tougher time learning which packages you fetch (though this part of the protection is not as strong, since maybe they can count bytes or something and guess).
As Debian's blog puts it:
"The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services."
Not showing the world what packages you fetch is good common-sense data hygiene, but it can also provide safety when you're updating a package due to a security vulnerability, and you don't want people to learn that you're running a vulnerable version right now.
How does it work from a technical perspective? The apt-transport-tor deb package introduces a new "tor+http" transport that you can use in your /etc/apt/sources.list file -- so while before you would typically list a Debian package repository as being an "http" address, now you can list it as being a "tor+http" address. Debian has its own official onion addresses for its package repositories, along with onion addresses for many of its other sites and services — and they even use Donncha's OnionBalance tool to provide redundancy and scaling. (Also, since the nice person who helps run Debian's infrastructure also helps to run our infrastructure, that means we now have onion addresses for many of Tor's sites and services too!)
You can configure your Debian system to update via Tor by following the directions at the bottom of the Debian blog post. A growing number of privacy-oriented Debian derivatives, including Tails, use apt-transport-tor as their default way of doing updates, and we think that's a great and important trend.
Hm! Yes, apt uses plain http to fetch its debs (and then checks the signatures afterwards), so it is possible that somebody somewhere on the Internet (the exit relay, an attacker at the repository, or somebody in between) could mess with those.
That is indeed one of the advantages of using the onion address for reaching the repository -- you get end-to-end authentication and encryption, which pretty much stops all of those types of possible attacks.
(Another advantage of using the onion address is that it shifts load away from exit relays in the Tor network -- which once thousands of people are using this for their package installs might add up to be a big deal.)
onion addresses give no authentication since rsa1024 is insecure
Sorry, but this statement is false: rsa1024 is not great by any means, but also it provides way more than 'no' authentication.
For the real answer, see the next-generation onion service design: