Hello
I’ve set sys-whonix as my ClockVM as I really want to get rid of insecure NTP. It appears to be working fine.
However I’ve found this ticket Qubes-Whonix-Gateway as ClockVM . Did it got implemented ? I think I’ve read elsewhere sys-whonix as ClockVM is bad because because the clock could be leaked when some AppVM connects to clearnet (identity linking).
I rarely use clearnet but when logging to i.e. banking sites I guess it doesn’t make sense to use TOR.
So would using an AppVM or DispVM based on Kicksecure template for clearnet solve the problem of clock correlation ? sdwdate in KicksecureVM could get clock from sys-whonix, adjust it a bit and then set time in the VM.
But I think that this is not what is happening. Instead in KicksecureVM tor connection is made and sdwdate obtains time on its own from onion services (same way that sys-whonix uses I guess). So this would result in an abnormal network pattern - 2 tor connections from 1 computer.
Although maybe for ISP its indistinguishable from 2 computers making 1 tor connection but both being behind same residential router - I don’t know.
A different ticket I’ve found is this one Create `sys-ops-whonix` VM for Enhanced Security and Isolation in Qubes-Whonix · Issue #9294 · QubesOS/qubes-issues · GitHub
So maybe I should create another qube based on whonix-workstation template and use that as ClockVM ?
Any recommendations how to do it better ? 
I don’t believe so, as the status is listed as status_open_issue_todo. I know Patrick and I have discussed how to implement this in the past but it got deprioritized since there’s more important stuff to work on at the moment (though we really want to get to this).
The ticket you linked to mentions some rationale behind wanting all VMs (or some VM groups? slightly hard for me to tell from the wording) to have slightly different clocks.
Kicksecure AppVMs (and all Whonix-Workstation and Whonix-Gateway AppVMs) all run their own separate instance of sdwdate at the moment. They are combined into one tray icon by sdwdate-gui, but it’s a bunch of separate instances, which may provide slightly different time values. If you don’t use sys-whonix as your ClockVM, this is what you get, and I think it’s also what you get even if you use sys-whonix as your ClockVM.
You would have two separate Tor connections from the same system indeed, and since the Tor daemons are separate they will probably use different guard nodes, which may look interesting. That being said, traffic going through one node shouldn’t be able to be correlated to traffic going through the other node, partially because the different sdwdate instances will give different time values.
I don’t think that will give you the “all VMs have slightly different clocks but from one sdwdate daemon” setup, which I think is the purpose of the ticket you referenced.
1 Like
Thank you!
I would get 3 VM groups:
- sys-whonix - unique clock on PC and the only one VM with a running TOR daemon,
- anon-whonix, sys-ops-whonix and rest of VMs based on whonix-workstation template - all having unique clock,
- all the rest - clock equal to sys-ops-whonix.
In practice the 3rd group would consist of:
- VMs without network connection,
- client VMs used for clearnet activity,
- service VMs related to networking: sys-net, sys-firewall, sys-vpn.
So the clearnet activity in group 2 could be correlated via clock. I guess this is not a problem as clearnet activity is non-anonymous anyway. What’s important is that activity in torified VMs can’t be correlated (neither with each other nor with clearnet activity).
Assuming sys-ops-whonix would be used for nothing else than source of clock would it be true ?
I’m not sure about group 3. Traffic from sys-whonix has to pass through those (sys-vpn being optional and recommended against officially).
But sys-net and sys-firewall will only NAT TOR traffic so maybe there is no place where the shared clock could leak ?