Tor story

[Kixunil]

Tor is a natural component that has to come eventually. We need to decide on the tooling, Infrastructure and Action.

@assassin4377 had a very interesting idea about tun interface and possibly isolation. That's something very useful for non-Qubes systems. It'd be also useful to make Qubes deployment easy.

Things to address

• [ ] Tor service files
• [ ] Should the package just use a single system Tor?
• [ ] Identity isolation - ideally there should be a framework for spawning new identities that are naturally isolated
• [ ] Should we try to use tun?
• [ ] Integration with torbrowser
• [ ] How to integrate into Qubes
• [ ] Possibly whonix VM for non-Qubes users?
• [ ] Turning on relay mode
• [x] Hidden services - outside
• [ ] Hidden services - RPC #24

[ghost]

@Kixunil thanks for the invite to conversation. here's some kickoffs.

• tor service files. in theory we could use a base torrc config with arg'd/parameterized setup on package install. similar to an installation on debian asking what timezone you're one/etc.
• Should the package just use a single system Tor?: can you clarify? as in a single tor service running? this is a strong decision point because it could affect other items in the list.
• Identity isolation - ideally there should be a framework for spawning new identities that are naturally isolated i agree on this one, the framework should be very simple and lightweight for it to be of value. i think taking a playbook from qubes and doing some sort of isolation is the way to go.
• Should we try to use tun?. i think the only con against tun would be if some sort of setup is going to use the namespace (ie like vpn/tunnel/etc). you could also namespace using udev as tor0 or something like that so it's expressive and clear to the user.
• Integration with torbrowser this could be a long conversation, maybe let's pin this one for now?
• How to integrate into Qubes also a potentially long conversation since networking in general is mildly more complex due to dom/qube isolation. 📌 for now.
• Possibly whonix VM for non-Qubes users? i think this would be a low-hanging fruit that's easier to pick. one of the painpoints on the qubes project is it won't run on just any hardware, whereas whonix will run on a toaster, provided toaster can run vbox/etc :-)
• Turning on relay mode this is slightly couple with the configuration/service files item. but it's trivial to hup a service and arg with relay/exit/bridge/router. likely it could all be setup from the beginning of package install. then the service runs in general and you can flip the mode pretty easily
• Hidden services i started spiking this one for a provisioning script i wrote on my infrastructure. if we decide the story is fine, i'll include it for review.

thanks again for including me and having a nice project!

[Kixunil]

Sorry for replying this late, I was researching this and was busy. Maybe something you should understand is that this project is meant to be installable on desktop, but also on a dedicated server (without desktop parts). It's already separated in the experimental repo.

• I meant interface files, sorry. I was thinking of auto-generating hidden services from them.
• Exactly, one instance for the entire system. I'm currently thinking about doing that by default, but if identity manager gets implemented, then run a separate instance for each identity to decrease the risk of side channel attacks.
• My current thinking is to provide an interface that will support just methods create_identity(identifier) and remove_identity(identifier) it could be a simple suid binary which would create a new user using scheme HEX(HMAC($USER-identity-$IDENTIFIER, $KEY)) or something like that to avoid linking with other identities if an identity is compromised. If a user is using Qubes, he should use differnet domains, but it'd be nice to provide some tooling for that too.
• I think tun should be just another package, so it wouldn't conflict with Qubes for instance, but could be useful for some users.
• I was mainly thinking if torbrowser should have a separate instance or not, o if there's anything interesting we could do (like for instance, if you run torbrowser using a certain identity, it opens bitcoin: and lightning: links belonging to the same identity.
• I have some experience with this and my currently preferred approach is to provide packages for Qubes RPC providers and for clients and something to wire them together. This replacecs firewall with something simpler.
• Yep, I was thinking if you create an identity on desktop, it will create a VM for you.
• The result from my research is that tor has ridiculous configuration in Debian by default not using conf.d. I think we should create a special "patching" package that just diverts the config file into the directory and installs one that includes the directory. I definitely don't want to do anything interactive in installation if not necessary.

[Kixunil]

I have split the hidden services into two parts: RPC and publicly facing interfaces. I think RPC should be shared and use v3 addresses.

[ghost]

I have split the hidden services into two parts: RPC and publicly facing interfaces. I think RPC should be shared and use v3 addresses. -> agreed. i favor this approach as well. v3 address makes more sense since it's forward moving.

i'll respond to other items shortly.

[Kixunil]

Note that main reason for choosing v3 addresses is that its knowledge could be used as authentication mechanism (I'm not saying that's the best idea right now, just really want to keep the opportunity and explore it. Even if there's need for better authentication, it may be nice safety net.)

[Kixunil]

Patching package done (issue #29)