My goal is to hide from ISP fact that I’m using Qubes OS. I disabled updates check for all qubes except Whonix-based ones (and disabled newtworking for non-whonix qubes at all for any case). But one thing left - it’s sys-net’s clocksync service. One guy already answered me that clocksync doesn’t leak information about Qubes usage, but it tells that I’m allegedly using Fedora OS, so I still prefer hide this fact 'cause Qubes users have the same clocksync pattern. So return to the question in the title: can I disable this service without negative consequences? My clock set proparly so I don’t think it really needs to check it every time every boot.
And the second question on the subject: was it all traffic (updates check and clocksync) that could leak Qubes usage or there is something else that can tell ISP that I’m using Qubes? Is it possible to hide from ISP the fact of Qubes usage at all?
The clocksync is done using the NTP protocol. AFAIK this protocol doesn’t contain any information about your system.
The IP packet could be fingerprinted as a Linux packet (it’s not super accurate though apart a whole class of operating system), but this could be a smartphone, a router, a smart TV or anything running Linux really.
by using a VPN
Why only VPN? Is it not enough just to disable clearnet update checking? My non-whonix qubes have no internet connection, updates check enabled only for Whonix-based qubes. Is it not enough for preventing Qubes usage leakage?
If there’s one thing Qubes is good at it’s digging network tunnels. Set up an I2P qube with an external outproxy (external anon server required) and route all your traffic through there. You can even chain Tor AND a vpn on top of that if you don’t mind a throwback to 1980s bitrates. Afaik I2P is good as an entry point because it splits your data into different connections and different types of connections (tcp/udp/ipv4/ipv6) in addition to mixing your traffic with randos
So nobody here knows if the steps I’ve described are sufficient to prevent an usage leakage? Nobody knows if update checks and clocksync are the only traffic that could give up Qubes OS (considering all the steps I’ve taken)? Why should I %@#k with some I2P qubes, proxies, external anon servers and other s%@| (stuff) if my steps were sufficient?
Try it. And let us know if you stumble upon any problems.
The rest of your configuration looks sound.
Set all your update qubes to sys-whonix (dom0, default update proxy, whonix update proxy).
You can test things with “tor control panel → stop tor” to see if manually triggered updates break or not.
There is something to do (like using Tor to fetch updates, or using a mirror that isn’t Qubes OS specific) to not be added to the statistics Statistics | Qubes OS
To start I just unchecked clocksync service. There were no any errors so far. Everything looks working as usually. On the second boot will remove this service at all, then set clock qube to “none” in Global Config.
Why test updating process if when you set sys-whonix as update proxy everywhere then all updates should be downloaded through sys-whonix? I always checked connections in onion circuits during updates and there always appeared different new connections to some unknown ips or to Debian adresses (or Fedora, if Fedora was updating).
While I remember: does Tails OS performs the same clocksync action during every its first connection to the Internet (I mean bootstrapping/network starting)? I know for sure that it performs some clock syncing and it is performed through clearnet but I don’t know if it is the same operation (I mean that looks exactly the same) as performs Qubes OS. It is important question.
To test if things really work as they should be.
Since the time when I completely disabled time sync there appeared these new messages in updates log. Not telling that it’s some problem, just inform you about something new related to this operation. Don’t know if it is something important.
Current default time zone: 'Etc/UTC'
Local time is now: Mon Feb 12 04:58:39 UTC 2024.
Universal Time is now: Mon Feb 12 04:58:39 UTC 2024.
Run 'dpkg-reconfigure tzdata' if you wish to change it.
qubes-sync-time.service is a disabled or a static unit not running, not starting it.
qubes-update-check.service is a disabled or a static unit not running, not starting it.
Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145.
is tor bridge sufficient? or do you really need VPN before Tor? thought of changing sys net of sys whonix to sys vpn, is it overkill though? since it will slow down internet slightly
up…
i would post exactly this as new topic. but then they would tell me it’s duplicate…
i really need the answers of the questions @Qubie posted exactly. especially considering https://forum.qubes-os.org/t/understanding-and-fixing-issues-with-time-clock/19030:
You can disable the clock sync service at will. In my experience there
are no negative consequences.
It has some, but minimal, effect on hiding the use of Qubes form an
antagonistic ISP
A clock desynced by a dozen seconds can produce unusable TOTP (depend when you type them), a more important desync (like 40s) will always generate wrong TOTP.
Otherwise, there should not be real issues as long as the difference is kept to a difference less than 1 hour or something. Maybe some specialized network protocols may not like it (thinking of iSCSI or NFS).
A desynced clock can cause issues with Tor bridges, even though standard Tor usage typically remains unaffected. Problems tend to arise specifically when using bridges due to their reliance on accurate time synchronization.
AFAIK, the only place where time sync might indicate the use of Fedora is in the FallbackNTP configuration. By default, this setting points to .fedora.pool.ntp.org, but it only sends clock sync requests to these NTP servers if all other primary NTP servers fail. To avoid this Fedora-specific reference entirely, you can modify the FallbackNTP server configuration to use the more generic .pool.ntp.org. This change removes any fallback-related mention of Fedora.
@unman, great! now what about the rest (more important):
If you don’t want to connect to remote NTP servers but you want a time synchronization you could create a local NTP server based on a GNSS source (GPS, GLONASS, Galileo, BeiDou, …). A GNSS signal is an accurate time source.
Search for NTP GPS with your favorite search engine/LLM engine, you will find a lot of guides to configure a NTP server with a GNSS receiver.
I assume that user who disable timesync will manually set time. In most
cases that works fine, even with bridges.
It’s not the fedora, it’s the pattern of network activity. And, as has
been pointed out before, those patterns are identifiable enough to
identify a Qubes-Whonix machine (given an adversarial IP with sufficient
resources).
I thought my answers were implicit in what I have said before.
No
No. A sufficiently resourced ISP will be able to identify Qubes or
Qubes-Whonix use.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.