This may not be the right category. Packet headers are one way that tracking companies and infrastructure keeps track of people. Qubes changes TTL numbers in unexpected ways because each VM can change TTL. Should Qubes by default correct this so the packets seem less Qubey upon arrival given that there are CLI ways to correct this?
What do you mean?
It is the default for the Linux kernel in all VMs:
user@dom0:~ > cat /proc/sys/net/ipv4/ip_default_ttl
64
user@sys-whonix:~ > cat /proc/sys/net/ipv4/ip_default_ttl
64
user@sys-net:~ > cat /proc/sys/net/ipv4/ip_default_ttl
64
I am not 100% sure, but all i know is other Linux/Android have TTL 64, and Qubes has TTL 62/63, (what a router sees). even when the Appvm itself has normal 64 TTL as setting, since every VM hop means minus 1 TTL, that means at the end sys-net has 63 TTL. And that unique number makes a Qubes user stand out (only locally), as a VM based system. To fix this is to set TTL as 65 in sys-vpn (with Wireguard), so when it leaves sys-net it is 64 TTL as normal Android/Linux users. Or if you dont have sys-vpn, force TTL 64 by rules in sys-net to force traffic leave your device as 64.
1 Like
Do you have a source on that? I don’t mean to sound combative; of course it’s possible but I’d like to know whether this has actually been reported in-use anywhere.
The discussion was a thing in the early years of the century but is of not much use today IMHO. It is just one (of a gazillion) metrics. For history’s sake…
1 Like
So, sys-net, to sys-fire-wall to sys-vpn to sys-whonix to Windows and suddenly the TTL is really incredibly unique. That’s a change of 5 to the TTL plus any changes from routers and almost no other users will have that, and it’s in the packet headers. You think AI doesn’t check packet headers? You think big tech doesn’t check packet headers? Yes, there are ways to check if something is in a VM, but these TTL differences are so unusual, it almost guarantees Qubes.
There should be some way of standardizing a Qubes TTL so this doesn’t happen. Why can’t Qubes by default adjust TTL by negative 1 for everything except sys-net? We should be have packets with 64 or 63 TTL, not packets with 61 or 60. It’s too strange, it immediately lets everyone know someone is using Qubes, and that’s actually a risk for hacking. For example, if I were a corrupt government and I am looking for the whistleblower who I suspect is using Qubes, I can look at the infrastructure for the packet headers and look: does anyone have 61?
And I am referring to both the packets arriving at servers and the packets seen during infrastructure transit from the computer to a data center if a VPN is used. @tommy can you correct this (or someone else) if I am wrong on technical elements? My math and conceptualization may be incorrect.
In my opinion, Qubes Team have other priorities and should focus mostly on security, so no one hacks your system when you are online. Users are free to fix things like TTL etc. It is not a big issue for tracking. I don’t see any adversary tracking your TTL across venues. There are other things that makes you stand out more.
In case you are the 0.01 percent that needs to have a TTL as 64 or is paranoid, you can postroute ip ttl as 64 in sys-net template, by adding rules in template. It will not slow your system and it will make sure a package of 64 leaves your system.
There are many more hops until the packet reaches “AI” or Big Tech. If anyone is to analyze your TTL, that would be your ISP and they already know who you are anyway.
There should be some way of standardizing a Qubes TTL so this doesn’t happen. Why can’t Qubes by default adjust TTL by negative 1 for everything except sys-net?
Qubes cannot predict your infrastructure and choose a proper TTL based on it. Consider cases with home LAN or SOHO routers. Consider also that sys-net is distrusted, so there is no guarantee it will just decrement the TTL and not do something else. If TTL is to be mangled (which I question), that would be on the exit node of your LAN (likely, also a distrusted proprietary device).
For example, if I were a corrupt government and I am looking for the whistleblower who I suspect is using Qubes, I can look at the infrastructure for the packet headers and look: does anyone have 61?
Even if whistle blowers were caught through TTL, and even if TTL was the only factor for detecting Qubes, a Qubes user still does not automatically constitute a whistleblower.
FYI:
2 Likes
I can use OpenWrt to automatically change all outgoing TTL values? Cool. I didn’t know that, thank you!
Anyway, a simple solution for those who don’t want to stand out with TTL 62 for a local observer.
Let’s assume you have a disposable sys-net (What is strongly recommended).
In the template dvm of your sys-net, for example debian-13-xfce-dvm, open terminal and add these lines in rc.local (sudo nano /rw/config/rc.local)
# Check name of vm first
REAL_VM_NAME=$(qubesdb-read /name)
# Only set TTL rule if it is sys-net
if [ “$REAL_VM_NAME” = “sys-net” ]; then
nft add table ip target_mangle
nft add chain ip target_mangle outbound_normalize { type filter hook postrouting priority mangle ; }
nft add rule ip target_mangle outbound_normalize oif != “lo” ip ttl set 64
fi
That’s all. You can test the result before and after running tcpdump:
sudo tcpdump -i wlan0 -nn -v outbound
I’d highly recommend something like this little guy:
If you think TCP/IP fingerprinting is possible in a meaningful way, it saves a bit of hassle since no obfuscation on your laptop is needed. Just run it with OpenWRT. Reflash it as often as you like. And just in case… compared to a laptop It’s an easy-to-dispose-of gadget.