This is a very cool name. I wish some other privacy projects could come up with stuff like this lol
in my experience it’s always open source projects coming with cool ahh names
Is it possible to install this on Fedora Workstation? If so, are there install directions available?
# Fedora 41 and newer
sudo dnf config-manager addrepo --from-repofile=https://repo.secureblue.dev/secureblue.repo
# Fedora 40 and earlier
sudo dnf config-manager --add-repo https://repo.secureblue.dev/secureblue.repo
# Install the package
sudo dnf install trivalent
Official support is only provided via secureblue. Unsupported installation is also possible via our repo. In addition to being unsupported, use of Trivalent outside of secureblue lacks SELinux confinement.
I wanted to try it out, but the repository doesn’t support updates over Tor and there are no plans to support it:
The updating over Tor provides security and privacy benefits:
And I don’t want to lose them in return for using this browser.
The benefits mentioned in the linked article only apply when using .onion mirrors, otherwise you are just obscuring your IP from the update host.
Additionally, many of those benefits are questionable. Especially since most of them are solved with https and signature enforced sources, and a VPN. Not saying there are no benefits, but they aren’t necessarily security related.
These are not only about .onion mirrors:
- The user cannot be uniquely targeted for malicious updates – attackers are forced to attack everyone requesting the update.
- The ISP cannot easily learn what packages are fetched.
This will protect you from targeted attack when adversary can compromise developer key to sign the malicious package (or use some 0-day to bypass the verification) and compromise the repository infrastructure (or forge certificate if they have access to CA) to send you this malicious package when you fetch the updates.
VPN don’t make you anonymous.
(messed something up with my old login, ignore the name change)
These are not only about
.onionmirrors
Yes, you are hiding your IP address. That is all that means.
- The ISP cannot easily learn what packages are fetched.
That is what HTTPS is for.
This will protect you from targeted attack when adversary can compromise developer key to sign the malicious package
No, it won’t. If a repo maintainer had their key exposed, they can issue malicious updates to everyone and anyone. Targeted attacks are pointless at that point, since I can target all Tor IPs or something.
or use some 0-day to bypass the verification
Again, bigger issues at that point.
compromise the repository infrastructure (or forge certificate if they have access to CA) to send you this malicious package when you fetch the updates
This requires signing key exposure, which again is a bigger issue that can’t just be fixed by hiding your IP. Especially behind Tor of all things.
VPN don’t make you anonymous.
Never said they did. But in this case, neither does Tor. In this case, you are just hiding your IP, so the benefit is based on the quantity of users doing the same as you. VPNs would provide the same protection.
And that’s enough to hide that this specific fetch request was coming from me and avoid being served the malicious package specifically targeting me.
If adversary somehow knows that I’m downloading updates from this repo over Tor but I’m not the only one who is doing it then without breaking Tor there is no way for adversary to target me specifically.
And adversary may be unwilling to target big number or users just to attack one specific target which could lead to the attack being exposed and cause serious damage to the adversary.
VPN is not providing you anywhere near the same protection as Tor in this case.
It’s possible to determine what files did you download when all files and their size are known:
And adversary may be unwilling to target big number or users just to attack one specific target which could lead to the attack being exposed and cause serious damage to the adversary.
This is rather hopeful thinking. In reality they will do what they need to with what they have. If you are using Tor and they really want to target you, then they will just target Tor users.
VPN is not providing you anywhere near the same protection as Tor in this case.
A VPN provides protection in correlation to the number of users using it, same as Tor. Especially so in this case, where most correlation happens through IP addresses.
It’s possible to determine what files did you download when all files and their size are known
Did you read the answer you linked? The exact case cited where it is possible is in exact contrast to how package managers download files. PMs do not download one file from one source, especially not one at a time. The complexity to deduce file sizes in other cases is very high. Above common attack vectors for security, and above common tracking techniques for privacy. Since there are a lot of considerations to take when sniffing that specific traffic.
Of course I don’t expect it to be a guarantee that the adversary won’t be able to compromise me this way, but this will be an additional hurdle for them to overcome and weight it out if it’s worth it to send the malicious package update to the big number of users just to target one specific user and risk to expose their 0-days/CA compromise/developer key compromise/etc.
It’s not the same.
To break VPN the adversary just need to compromise the VPN server (or force VPN provider to assist them).
To break Tor the adversary needs to carry out a much harder attack that will require more resources:
It’s said that it’ll be hard to determine if the file download was cancelled and retried.
For example, if I’ll only download/update Trivalent from this repo using package manager, then it’ll first download repomd.xml, maybe some other repo info files, then the trivalent rpm. But the downloaded files will be the same for everyone that will try to update the trivalent package and the total size of all these downloaded files could be calculated and compared to the files in repo to determine which files were downloaded.
this will be an additional hurdle for them to overcome
You mean an additional deterrent, it does not physically or logically prevent them from targeting you.
risk to expose their 0-days
This is a very specific scenario, usually when an attacker has a zero day they want either a specific victim, as many victims as possible, or both. Like I said earlier.
CA compromise
Compromising the host’s CA is not sufficient to push malicious updates. This is why some package managers still use http mirrors.
It’s not the same.
You’re moving the goal post here. We were talking about a targeted attack from the update server’s end. From this perspective, they are the same.
We can take it many steps further than this if you want, but it wouldn’t be a fun discussion.
It’s said that it’ll be hard to determine if the file download was cancelled and retried.
Or if multiple files of similar size are provided. Which is not a rarity from package sources. Even then, what advantage do you gain by hiding this in the case of Trivalent?
At this point this is very off topic, so lets just agree to disagree at this point. But, to summarize, your entire point is that targeted attacks are harder. Which is true, but that has little direct effect on security, more of a privacy effect than anything.
It prevents them from targeting only one person specifically (not as part of a bigger group) without breaking Tor.
The VPN and Tor will be the same if the adversary will send malicious update for a group of users that use this VPN or Tor.
I’m only considering a case of, for example, a nation state level adversary targeting a specific person and they don’t want to risk that being discovered by sending the malicious updates to the big group of users for it to end up in the hands of some malware researcher.
This is a part of an attack, not the only requirement as I’ve stated before:
(developer key compromise OR use some 0-day to bypass the verification) AND (repository infrastructure compromise OR CA compromise)
That’s why I was talking about a possibility to determine the downloaded files.
This won’t help in protecting against targeted attack, it’s more about privacy in general in this case.
It could’ve helped in the case of targeted if it was possible to mask the Trivalent to some other Chromium browser so that the adversary won’t know that you’re using Trivalent and won’t target it, but I don’t think it’s possible to hide it by changing user agent etc, I guess there still will be some fingerprint specific to Trivalent in the end.
I’m only considering a case of, for example, a nation state level adversary targeting a specific person and they don’t want to risk that being discovered by sending the malicious updates to the big group of users for it to end up in the hands of some malware researcher
I believe I said this, that is a very specific use case. Especially since in such scenarios you probably should not be using a desktop device and expect security. Eventually, the desktop security model as a whole becomes a risk.
This is a part of an attack, not the only requirement as I’ve stated
Wording was confusing there. Made it sound like it was one of the potential attacks, not a prereq.
That’s why I was talking about a possibility to determine the downloaded files. This won’t help in protecting against targeted attack, it’s more about privacy in general in this case.
… k? So there is no security benefit. Which is my point.
It could’ve helped in the case of targeted if it was possible to mask the Trivalent to some other Chromium browser so that the adversary won’t know that you’re using Trivalent and won’t target it
Target it how? Trivalent doesn’t add anything new to target. If you mean targeted attack, ie Trivalent (and by extension Chromium) is vulnerable to something and someone intends to use it against Trivalent specifically. It is likely possible to do that, as you said, with fingerprinting.
I don’t think it’s possible to hide it by changing user agent etc, I guess there still will be some fingerprint specific to Trivalent in the end
Yeah, anti-fingerprinting is not a goal of the project.