Use Onion Services for APT
Currently, /etc/apt/sources.list makes use of apt-transport-tor (tor+http://) to fetch the repo lists from the normal Debian mirrors via the Tor Exit node.
This could, however, be done through Tor entirely since there exist official mirrors that are Tor Onion Services, such as vwakviie2ienjx6t.onion.
- Traffic stays within Tor, avoidance of metadata
- End-to-End encryption to the Onion Service
- (debatable) Fingerprinting of Tails users (what diffs were missing? when was the last package list update?) at the Tor Exit might become more difficult
- Adds load to the Onion mirror
- Packages signed with GnuPG anyways
- Might be slower than non-Onion Service access
Related to Tails -
#5 Updated by hans 2016-07-31 14:05:59
apt traffic is forced over Tor using iptables rules, then you can use .onion addresses without having
apt-transport-tor installed. Then .onion address then enforces that all traffic goes over Tor. Now that weasel has added official Onion Services for both the main archive and the security archive, this is possible to setup.
#6 Updated by intrigeri 2017-01-08 10:02:15
- Subject changed from Research whether we should use Onion Services for APT to Use Onion Services for APT
- Assignee changed from flapflap to intrigeri
- Target version set to Tails 2.10
- Type of work changed from Research to Code
> (Meta: I made it clear to flapflap before he opened this ticket that to be useful, it had to take into account previous security discussions about similar topics, so I’m assigning it to him so he can do that.)
I did the “let’s see what is blocking this?” dance, and the next steps I had documented (
Feature #8143#note-14) are off-topic on this ticket:
- we already use
apt-transport-tor, so there’s no additional code introduced by switching to Onion APT mirrors;
- there’s an obvious solution to the build-time / apt-cacher-ng issue:
And if we ever want HTTPS on top of Onions, well:
apt-transport-tor supports that :)
So I’m going to deprecate
Feature #8143 in favor of this ticket, and prioritize this topic higher since https://www.debian.org/security/2016/dsa-3733 has shown us that security in depth has some value here.
#7 Updated by intrigeri 2017-01-08 10:15:32
… except that we don’t provide any Onion service for http://deb.tails.boum.org/, and it’s enough to have one APT source that’s not authenticated end-to-end to weaken the whole thing. So either we need to fix that infrastructure problem first, and use the new Onion service; or we use HTTPS for that repo, but then the concerns about increasing the attack surface (discussed on
Feature #8143 already) re-appear.
#8 Updated by intrigeri 2017-01-08 11:09:25
> … except that we don’t provide any Onion service for http://deb.tails.boum.org/, and it’s enough to have one APT source that’s not authenticated end-to-end to weaken the whole thing. So either we need to fix that infrastructure problem first, and use the new Onion service; […]
Done, deb.t.b.o now has its onion service: http://jenw7xbd6tf7vfhp.onion/