This is a great idea, especially for TAILS users.

I've long been concerned about updating a TAILS image to get the latest security updates and leaking forensically-useful data. By using hidden services for apt-get updates, everything is over Tor, so this becomes less harmful.

But if you're using services through tor, aren't you already anonymous? It's my understanding that a hidden service is meant to hide the service, not the users. Hiding its users is only a byproduct of being part of tor.

I never saw a practical point to big projects and organisations like Debian having hidden onion-services. Other than promoting Tor it seems to me that hidden services are meant for other applications.

With a hidden service, your traffic never exits out of the the Tor network. There is no possibility of the exit node being compromised or spying on you.

I completely missed that vital detail. Thanks for correcting me.

Hidden services protect both parties better because there is no longer reliance on exit nodes.

I could imagine a scenario where a specific target was identified by the version of several potentially vulnerable packages they installed. The NSA monitors when this target is online (possible even through Tor) then listens to a specific set of upgrade requests for debian during that time.

Probably waiting for an upgrade into a version that they have found a vulnerability in.

By using a Tor-network internal address rather than an DNS/IP address, a Tor hidden service can provide integrity and confidentiality assurance over the Tor network's protocol rather than HTTPS.

but.. for apt archives, the integrity is provided by gpg.. TLS doesn't really add value for this.. However, it does provide confidentiality, such that an actor MITM'ing can't see what software is being downloaded.

Looking at the actual list of packages being requested isn't the only way to see what software is being downloaded.

An attacker could also see the size of the packages being transferred. Using the dependency tree would help in determining what packages have been downloaded.

Though I admit this is a higher barrier than just reading the list of packages.

There are multiple layers of encryption you get for free by using a tor hidden service.

Defense in depth.

It's a nice but something more efficient would be some automated way to discover the onion services for domain while staying in the onion network. Like being able to have onion domains like backports.debian.org.onion or having some sort of protocol upgrade when accessing backports.debian.org with a Tor-capable client.

But how would that work? You'd have to have some kind of bootstrap hidden service which would essentially act as a DNS or search engine. But as soon as that service exists, you have again a single point of failure.

Require them to use the same cert as for their main site, so a CA compromise is required.

Also have it published in certificate transparency databases, so a targeted attack is impossible.

You can have multiple nodes broadcasting the same hidden service ID. The name collision this causes will let you use the tor network as a load balancer.

Some sort of DNS attribute might work.

On the same topic, there's a fork of HTTPS Everywhere to do this exact same use-case: https://github.com/chris-barry/darkweb-everywhere

How about a seperate DNS-record, like CNAME only pointing to an onion address? (I'm still pissed most new DNS records abuse TXT to improve adoptin speed by the way)