blocking networking until sdwdate finished

Development
, ,
1

sdwdate-gui is not started by default in #Qubes because make sdwdate-gui Qubes friendly is not done.

Once we have that graphical user interface part done and once we have enable sdwdate-gui systray by default done and a ton of testing we can get a new #anonymity feature:

iptables block network access until #sdwdate succeeded.

Instructions for testing:
Network Time Synchronization - Whonix

2 Likes
3

There has been some work on sdwdate-gui for Qubes for a while. I was waiting for Whonix 14 to be officially released before calling for testers. Did not update ⚓ T534 make sdwdate-gui Qubes friendly (sdwdate-gui-qubes) (lack of time).

GitHub - troubadoour/sdwdate-gui

The installation is straightforward for the templates (whonix-gw-14 and whonix-ws-14 for the time being) but some files have to be installed in dom0 too.

I could write some installation instructions for testers, depending on an answer. Will the name of the templates and gateway include version number in Whonix 14 release?

Current status:

  • sys-whonix menu includes Tor status and Tor control panel, providing GitHub - troubadoour/tor-control-panel: Tor controller is installed.
  • the anon vms menu are the same as old sdwdate-gui.
  • the anon vms are registered when starting.
  • the anon vms are unregistered when powered off normally, not when killed.
3 Likes
4

That’s great! Yes, please write the instructions for testers!

Yes.

whonix-gw-14 and whonix-ws-14

5

Which means sys-whonix-14 too ?

1 Like
6

No. Only templates will be versioned.

Names sys-whonix and anon-whonix stay as is.

Reference:

7

Documentation is now here:
Network Time Synchronization - Whonix

8

Iptables now deprecated and replaced with nftables, better to change to nftables for future support and avoiding issues.

9

https://phabricator.whonix.org/T509

1 Like
10

I used this in qubes it works good except it doesnt resume so well if Tor didnt first time worked properly (like there is no connection at first time, or delayed tor run…) specially in GW, but otherwise works ok.

1 Like
11

Side question:

Why it need to be implemented in both WS and GW if tor and internet are only in GW anyway?

1 Like
12

This feature needs more work.

  • Needs instructions for users how to test this feature.
  • Enabling this feature using firewall_mode= is quite unusual and weird.
1 Like
13
  • Whonix-Gateway: The user’s clock might be slow while at the same time an outdated Tor consensus was sent to the user (man-in-the-middle attack) (replay attack). If sdwdate manages to connect to onions to fetch the time and it knows the time is later then the VM clock, it will move the VM clock forward. Tor would notice the time change, disregard the outdated Tor consensus and download a fresh Tor consensus or fail closed. The goal is to wait for a “guarantee” that the user’s system clock isn’t slow before permitting “all” Tor connections. “All” means other than just only Tor and sdwdate over Tor.
  • Whonix-Workstation: Applications might leak the VM time to remote servers. Therefore wait for sdwdate to set and randomize it so it’s guaranteed to be different form the host (and Whonix-Gateway).

More on all of these technical considerations here:

1 Like
14

documentation issue: