Hi,
I have a question regarding chaining my qubes to have best anonyimity/privacy. I have the following qubes:
sys-net: Default qubes for network
sys-dnscrypt: running dnscrypt
sys-vpn: running a vpn with wireguard
sys-whonix: default whonix gateway
Which chaining would be best to have best privacy/anonymity for:
I would like to have dnscrypt proxy for both situations
Thanks in advance!
Without knowing how you make sys-dnscrypt available to your qubes, I
cant comment there. You have not said what roole the VPN plays in your
set up.
The canonical advice from the Tor project is:
This is long standing advice, and a detailed comment is here
I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.Thanks for your reply! I used your dnscrypt salt, which works just perfectly. So any qube that uses sys-dnscrypt as netvm, will use dnscrypt
But to answer your questions:
1 - sys-net < sys-firewall < AppVM
2 - sys-net < sys-firewall < sys-whonix < anon-whonix / AppVM
For non-Tor traffic I would consolidate sys-vpn and sys-dnscrypt into the same qube as long as the dnscrypt daemon is implemented in a language that has at least some memory safety such as Rust (GoLang sucks a lot but would be acceptable). I would also use modern Landlock sandboxing and kernel hardening that Linux has and have the service manager start the dnscrypt daemon as an unprivileged user. With a dnscrypt daemon implemented in a memory safe language and a hardened kernel configuration I think having the dnscrypt daemon and my side of the Wireguard tunnel running on the same Linux kernel is probably okay.
Another thing you can do is route dnscrypt traffic through an additional Wireguard/other tunnel that belongs to a different VPN/proxy provider. Ideally this additional tunnel would be QUIC with encrypted hello using a hybrid “post quantum” plus elliptic curve cipher. As of OpenSSL 3.5 there is support for hybrid “post quantum” plus elliptic curve TLS.
Regular network traffic could be local client → proxy0 → internet with dnscrypt traffic being local client DNS request → local dnscrypt → proxy0 → proxy1 → remote DoH server.
Another thing you could do is route dnscrypt traffic (that serves DNS requests to regular traffic) through Tor. Your regular traffic would still be local client → proxy0 → internet. But your dnscrypt traffic could be local client DNS request → local dnscrypt → proxy0 → proxy1 → Tor → remote DoH server.
The major caveat with this approach is you could get funky DNS responses based on assumptions made by CDNs or based on assumptions based on geography. However, if you are using Mullvad to its full potential, where your Mullvad path looks like closest Mullvad gateway → Mullvad home jurisdiction (Sweden?) → less far Mullvad gateway → internet then you probably don’t care about funky DNS responses based on obsolete assumptions (around CDNs or geography) anyway.
Some do closest Mullvad gateway → Mullvad home jurisdiction (Sweden?) → less far other tunnel provider → internet. What “less far” means here is, suppose you want to access a server either in or near your own country, you can have the “exit” hop in a nearby country or in the same country. When you do this you can also run a bit torrent client that has a path closest Mullvad gateway → Mullvad home jurisdiction → distant proxy on other provider → internet re-using the same first two Mullvad hops. If you look for a torrent out there that never does not have abundant seeders you can find one easily and a script can continuously monitor and delete for perpetual re-download of the torrented data while another continuous script dynamically adjusts the bandwidth throttling on it. This makes the traffic between you and Sweden (we are using Sweden as an example here) look different than the traffic between the “exit” hop and the destination which your local jurisdiction and its partners are monitoring.
A single Mullvad hop is good but is probably not too much of a challenge for the big adversaries. These more sophisticated multiple hop approaches are at least a minor headache for them.
The big downside to multiple hops is that it chews up MTU. Some of Mullvad’s documentation suggests to use Wireguard (or something newer based on QUIC?) for the first hop and use SOCKS5 on top of that. Maybe this is the right approach if the SOCKS5 servers are using newer “post quantum” crypto for the handshake and strong symmetric ciphers for transport. Other than that, Mullvad’s multiple hop documentation seems to be kind of ambiguous.
Look at the output of mullvad relay list | grep '(Mullvad-owned)' and consider jurisdiction. Anything in mullvad relay list | grep '(rented)' in a country that has surveillence statutes that compel a provider to secretly cooperate is more likely to be compromised.
If you are like I am comfortable carefully crafting NetFilter rules for constructing Wireguard tunnels that do multiple hops and tuning MTU, go for it. If you pay both proxy providers in Monero XMR or something similar that will likely help you more than having the very best technical implementation.
Depending on where you are, you can also have an advantage of intentionally setting a tertiary Tor hop that is in Russia, followed by another hop then .onion destination or exit node. They will not like when you do that. If you reach an i2p node from a Tor node located in Russia, they will really not like when you do that.
If you happen to see Keir Starmer, run him over with your car.
