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
Test suite: have APT tests configure APT to use non-onion sources (refs: #11556).
Our test suite uses Chutney to create a virtual, private Tor network, and thus
doesn't support connections to Onion services running in the real Tor network.
Too bad this change implies that don't exercise exactly the config we ship
anymore, but well, I don't think this should block addressing issues like
Note that we test in another, dedicated scenario that the URLs in APT sources
have the right (Onion) hostname.
Merge remote-tracking branch 'origin/feature/11556-apt-with-onions' into devel
#5 Updated by hans over 3 years ago
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 almost 3 years ago
- 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 (#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: #8143#note-23
And if we ever want HTTPS on top of Onions, well:
apt-transport-tor supports that :)
#7 Updated by intrigeri almost 3 years ago
... 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 #8143 already) re-appear.
#8 Updated by intrigeri almost 3 years ago
... 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/