I agree. I was only proposing this as a way to prevent direct traffic from the operating system to Fedora servers.
1 Like
That one guy is also telling you the exact same thing here, too.
What’s stopping you from specifying your NTP servers as time.windows.com or ntpserver.contoso.com, time.apple.com or clock.adatum.com, or something else that Windows or macOS machines would use; and specifying a custom clocksync interval that mimics that of Windows or macOS?
Is that not a viable option for you? And if not, why?
Do you even know what the ISP can see when anything leaves your machine?
Assuming you’re on IPv4 only (as standard on Qubes OS), your WAN/LAN router will be masquerading your packets (taking your name off them and replacing it with its name before sending them over WAN, so they’re actually deliverable)
The ISP will not be able to see any OS information. In all honesty, they’ll likely see a couple of NTP requests to a bunch of random servers, maybe a few plaintext DNS requests (if your LAN has something on it that doesn’t use DoH) and a lot of data packets going to IP addresses on the Tor Project’s node register.
Oh, and whatever else is on your LAN too. The ISP don’t explicitly know which device inside the LAN is sending those packets, which actually works in your favour, by mixing your traffic in amongst other devices.
But that’s pretty much it.
Let’s play devil’s advocate. What if you connected your Qubes OS machine directly to your ISP modem (not the router, the MODEM) and put the unfiltered internet into your Qubes OS machine?
Well, the ISP would be able to see your NIC’s MAC address (or at least, whatever MAC address your NIC decided to declare, which could be randomised), and if someone decided to nmap your WAN IP (so, check your Qubes OS machine for open ports and OS detection)…
I went ahead and did this for you, and this is the output of nmap:
Nmap scan report for XXX.XXX.XXX.XXX
Host is up (0.17s latency).
All 1000 scanned ports on XXX.XXX.XXX.XXX are in ignored states.
Not shown: 1000 filtered tcp ports (no-response)
MAC Address: 13:37:13:37:13:37 (Unknown)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop
Hopefully this alleviates some, if not all your concerns about what your ISP can and can’t see.
Yes, with enough data, and pattern correlation as @unman stated, a network operator might be able to guess there’s a Qubes OS user somewhere on their network, but I can promise you, it will not be your NTP packets that allow them to.
Honestly, I’d be more concerned about what you’d be leaking to the web servers you’re interacting with. They can see a lot more than ISPs, because they’ve got the HTTPS keys.
Don’t believe me? See for yourself:
2 Likes
Hello, buddy! I’m glad that I’m not the only one who’s interested in such things and tries to convey the thought to the developers that Qubes should improve work on system anonymity too or at least with new system versions provide users simple “switches” to patch anonymity holes that they are aware of.
Finally got to this thread, read all and can say that it’s already more than year has passed since I disabled time sync and set UTC time in bios, and used bridges all that time - and had no issues EVER. Even if sdwdate failed sometimes this was due to the larger number of allowed offline servers.
1 Like
Unless you, not consciously, perform update checks via clearnet, when your dom0 searching for updates on Qubes specific servers.
So that’s why I repeat (don’t know, maybe it’s already implemented in latest Qubes versions, since didn’t installed Qubes a long time) that there must be a warning in Qubes installer saying that updates over Tor feature DOES NOT hide Qubes presence for your ISP and made not for this. Or even better - there must be one single switch in installer, disabling all update checks/downloads by-passing sys-whonix, with little explanation about the need to disable networking for all non-whonix user qubes and removing all the new created qubes from update checks list (if user is interested in maximum reduced fingerprint). Or at least as minimum - add small explanation in installer what user can do to reduce Qubes OS fingerprint and how updates over Tor feature really works. 'Cause it seems majority of users really misunderstood its purpose.
1 Like
Let’s say my sys-net is based on the Fedora template. What will be the clocksync interval on my Qubes system?
Will the clocksync interval on my Qubes system (with a sys-net based on the Fedora template) be the same as on a regular Fedora system used as a host?
I would also appreciate it if you could show me how I can check it.
1 Like
See for yourself:
timedatectl timesync-status
Most likely, yes.
I don’t think any of the Qubes OS mirrors are “dedicated”, or at least, very very few are…
2 Likes
Thank you for your reply alzer89
I typed the command and read the result. Should I pay attention only to the line “Poll interval:”, or should I also pay attention to something else? As a result of the command, other data also appear (I don’t know if they are relevant in this matter).
1 Like