Onionizing Qubes-Whonix Repositories

Qubes-Whonix
1

I understand this is coming up for Whonix 14 - see https://phabricator.whonix.org/T399 - but it is worth re-iterating that hardening the current stable Whonix 13 can be achieved by defaulting the mirrors in sources.list to .onions

The benefits include:

  • protection against MITM attacks due to the use of end-end encryption;
  • protection against downgrade attacks; and
  • reducing the load on exit relays in the Tor network.

Is editing the sources.list already documented? I forget.

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.)

…

Also I think it’s important to note that, like targeted delivery of a malicious package, Tor forces the adversary to deliver malicious data to all users during a downgrade attack. Usually a malicious package will be caught when it’s signature is verified, but during a downgrade attack, the package is (was) a legitimate package so it’s signature is good, except the server delivers an older version of the package (or hides the new one from the victim).

Thus, the signature is good but the package is intentionally outdated; very useful for adversaries wanting to exploit vulnerabilities that were present in old packages but have since been patched. Tor means that everyone would receive the old version, making the attack much more detectable. Some package managers already protect against these kind of replay attacks using signed repository (as opposed to just package) files, but many do not.

1 Like
2

Yes.

Ultimate Nitpick: General, not Qubes-Whonix specific hardening. :slight_smile:

So in short, no, I don’t think switching to onion sources is documented. But very much worth it. Where to best add it? Security guide?

Once Whonix 14 is released, that adding onions should be prefered even when adding third party sources - needs to be added somewhere here: Install Additional Software Safely

3

Here’s the Qubes-specific part: I’ve been completely onionized for months - except for Qubes!!! What’s wrong with those kids? I think you need to get involved.

Related:
Update repos as Tor hidden services (onions) · Issue #2265 · QubesOS/qubes-issues · GitHub
https://github.com/QubesOS/qubes-issues/issues/1352

Tor is Whonix’s specialty within Qubes. Is there room on deb.kkkkkkkkkk63ava6.onion to host a yum.qubes-os.org mirror?

1 Like
4

Free disk space and traffic, yes.

Technical implementation is not super simple. Would might require support from Qubes. They providing rsync access or so. Then we could add a brain dead script that downloads from yum.qubes-os.org to whonix.org server over unencrypted connection (sorry, that is how rsync and mirroring works nowadays still). If domain name is supposed to include qubes-os.org, then further help from Qubes would be required (they modify DNS, point to whonix.org server) and I’d likely could use fortasse’s help for that one whonix.org server side.

1 Like
5

:unamused:

@marmarek, what do you think?

1 Like
6

ohnoes… SPIES!!!

7

There is already rsync service on ftp.qubes-os.org (which is the same as yum.qubes-os.org). Exactly for this purpose.

Repository metadata is authenticated anyway, so it shouldn’t be a problem.

I don’t understand. If that’s about above mentioned onion service, it shouldn’t have anything to do with qubes-os.org nor whonix.org domain, no?

One more possible problem - managing sources.list. Onion links needs to be placed there, but the file currently is part of qubes-core-agent package, which is generic package also for non-Whonix.

1 Like
8

How often could the rsync script run? (Keeping the time the mirror lags
behind low and not flooding Qubes server.)

marmarek:

[quote=“Patrick, post:13, topic:3221”] Technical implementation is
not super simple. Would might require support from Qubes. They
providing rsync access or so. [/quote]

There is already rsync service on ftp.qubes-os.org (which is the same
as yum.qubes-os.org). Exactly for this purpose.

Great!

[quote=“Patrick, post:13, topic:3221”] Then we could add a brain dead
script that downloads from yum.qubes-os.org to whonix.org server over
unencrypted connection (sorry, that is how rsync and mirroring works
nowadays still). [/quote]

Repository metadata is authenticated anyway, so it shouldn’t be a
problem.

Not a blocker, but here is why I brought that up:
Yes, repository metadata authenticated. But with rsync we are taking
something from a “somewhat secure” source (https), download it over an
insecure unencrypted rsync transfer. It would be bad if during that
unencrypted transfer a mitm introduced a malicious modification that
later exploits the metadata verification code in dnf.

So I think very long term, an encrypted/authenticated replacement for
rsync is desirable. [No such project exists yet to my knowledge.]
Ideally, packages were uploaded over a secure connection and then
downloaded by the user through an onion service. Then there are fewer
chances for a mitm to try exploit the metadata verification code. (Only
on the upload then server side then.)

[quote=“Patrick, post:13, topic:3221”] If domain name is
supposed to include qubes-os.org, then further help from Qubes would
be required (they modify DNS, point to whonix.org server) and I’d
likely could use fortasse’s help for that one whonix.org server
side. [/quote]

I don’t understand. If that’s about above mentioned onion service, it
shouldn’t have anything to do with qubes-os.org nor whonix.org
domain, no?

Files then would be available through

If that sounds alright, then there is no issue.

One more possible problem - managing sources.list. Onion links needs
to be placed there, but the file currently is part of
qubes-core-agent package, which is generic package also for
non-Whonix.

That could be considered a follow up task. For the context of this
Hardening Qubes[-Whonix] thread (which would document how to change
this) it is not a blocker.

9

Would it be cleaner to add another hidden service using http://qubesosmamapaxpa.onion/ or a newly generated http://qubesosxxxxxxxxx.onion?

1 Like
10

Maybe. But also more work. And depends on if it should be considered a
mirror or official location.

11

How often could the rsync script run? (Keeping the time the mirror lags
behind low and not flooding Qubes server.)

Generally there is not much load there, but better not more often than
once an hour.

Not a blocker, but here is why I brought that up:
Yes, repository metadata authenticated. But with rsync we are taking
something from a “somewhat secure” source (https), download it over an
insecure unencrypted rsync transfer. It would be bad if during that
unencrypted transfer a mitm introduced a malicious modification that
later exploits the metadata verification code in dnf.

I think that’s wrong assumption. Better assume server is always
compromised. HTTPS and/or tor is only for privacy (ISP can’t see what
updates are you downloading), but not for updates/metadata integrity.

Files then would be available through

If that sounds alright, then there is no issue.

I think that’s ok. If there is no conflict on directory names.

12

Additional benefits of doing updates via Tor, from a recent Tor blog post on apt-transport-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.

13

Yes, that’s right too. But it still does not depend on data integrity on
the server itself. Rather, makes it harder for attacker to provide
different data to selected users - so replaced packages can be spotted
even easier.

14

Right. I was replying to the “only for privacy” part. I just thought it
was worth remembering (reminding myself, really) that there is a
security benefit to doing updates over Tor in addition to a privacy benefit.

15

Good you say so, because I had in mind to only wait 1 to 3 minutes between checks.

Agreed.

“Better assume server is always compromised.” is a very good assumption.

Unencrypted/unauthenticated rsync also opens up for “trolling attacks”. What in case kkkkkkkkkk63ava6.onion ever delivers a malicious file? Then the investigation would have to cover:

    1. developer machine compromised?
    1. upload between developer machine to Qubes server compromised? (ssh has its weaknesses…)
    1. unauthenticated rsync between Qubes and Whonix server compromised?
    1. Whonix server compromised?

That would cost a lot time to figure out. If there was an authenticated rsync alternative, I would be very much for it. Alternatively, we if could check the integrity on the server before delivering it to users and having them notice a signature is broken would also be better. (avoiding lots of support requests and concerns) I guess it falls into the “very far in the future” milestone.

16

An option for pulling files in an authenticated manner is something like rsync over rssh. I’m not sure what the implementation difficulty would be on the Qubes side, it may not be worth the effort.

1 Like
17

Our wiki instructions to add “tor+” in front of the onion addresses for repositories is wrong, because you get a bunch of these error messages:

W: Failed to fetch tor+http://sgvtcaew4bxjd7ln.onion/dists/jessie/updates/non-free/binary-amd64/Packages Failed to connect to localhost port 9050: Connection refused

E: Some index files failed to download. They have been ignored, or old ones used instead.

Just pointing to the .onion mirrors without “tor+” works fine. So what’s the correct method?

1 Like
18

Making tor+ working in Whonix 13 is not simple.

Any invocation of apt-get - in essence - results in torsocks apt-get for stream isolation. I.e. apt-get gets forced to use a Tor SocksPort. This conflicts with apt-transport-tor which wants to connect to localhost 127.0.0.1 9050, which gets blocked by torsocks. (torsocks by default blocks that, because when not using Whonix, this is better blocked to avoid leaks.)

Running apt-get.anondist-orig would work for tor+, but that would break non-onion repository access on Whonix-Gateway, because that does not have system DNS.

tor+ needs to wait for Whonix 14, because that will be based on Debian stretch, which comes with a recent enough version of torsocks supporting AllowOutboundLocalhost 1 which will be enabled by the uwt package.

# Set Torsocks to allow outbound connections to the loopback interface.
# If set to 1, connect() will be allowed to be used to the loopback interface
# bypassing Tor. If set to 2, in addition to TCP connect(), UDP operations to
# the loopback interface will also be allowed, bypassing Tor. This option
# should not be used by most users. (Default: 0)
AllowOutboundLocalhost 1
1 Like
19

There is deb.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion - should be fine to use? @fortasse

20

To move this forward… To fully onionize all default repositories that Whonix is using for Whonix 15…

Could someone work please on

? Should be a rather simple task.

That would be a prerequisite to get this implemented in Whonix.