-Forgive my question is it seems rather slow, but how would the web fingerprint differ? A global community of Tor users will give different host time if their torbrowser is queried by a site's JS.
There would be the time users are using that are most likely using NTP and be the time users are using that are most likely using anondate. Browsers still do leak it in lots of places (https://trac.torproject.org/projects/tor/ticket/3059).
-About complaints, people already know that the purpose of timesync is to make Whonix's time differ from the host's.
Yes, but it is somewhat accurate, not wrong by an hour.
And one point that I failed to explain, this whole “time from verified consensus”… It is a lot less great and magic than you think.
First, replaying a consensus older than one week or so results in preventing access to the Tor network, and that's all, because onion keys will be wrong. An attacker who is in a position to replay a consensus to you could anyway do this, unrelated to time, so the issue at hand boils down to replaying a consensus not older than one week or so.
So an ISP level adversary could send an old Tor consensus that is 6 days old. The "time from verified consensus" could result in a clock that is 6 days too slow.
You can still verify messages that I signed with gpg a year ago. And those also include a signed time stamp from my local machine. Should you set your clock to it just because you can verify that time even if you trust that I didn’t forge the time? No. The trick with Tor is, that relays won’t accept any connections from someone that uses keys from a consensus that is older than a week.
So the issue you want to solve here “guard against MITM, be more resilient against MITM” changes the MITM target from remote ssl web servers and breaking CA’s to Tor where a MITM is in fact much simpler, since an adversary only needs to replay an old Tor consensus without even needing to break CA’s.
In case of Whonix, things would go even worse with solely relying on Tor Consensus Method rather than Remote Web Servers Method. At the moment ISP level adversaries can do a denial of service, but not influence the users clock, because that comes from remote web servers that are asked through Tor. On the other hand, with Tor Consensus Method, ISP level adversaries can decide what consensus they will be feeding the user, and guess in what range anondate will set the users clock then. And if they additionally also control some remote web servers that the user is visiting and JS leaks the time, they can easily guess which user they just have deanonymized.
- Hidden servers are ideally supposed to revel as little information about themselves as possible.
Supposed to, but hiding that information isn't documented for lots of service perhaps it is not even possible due to lack of feature or even required (this forum needs some kind of time for example).
[quote]Hidden services can only be accessed if the clock is no more than 30 minutes slow or fast. [/quote]
Read the ticket, seems to have been a bug that has been patched since.
To what value have they changed it?
[quote]As per Comparison with Others#Fingerprint, quoted from the Tails Design about Time syncing: "Our initial time guess based on the Tor consensus is probably easier to fingerprint, though: a fresh Tor is started, and restarted again right after the consensus has been downloaded." [/quote]
If the time is off Tor won’t be able to start though.
It is the terminology “won’t be able to start” that is ambiguous and problematic here. It means, “it starts, attempts fetching the consensus, but then won’t be able to establish circuits. It’s trying though.”
Then a refresh of consensus is warranted. If Tor can work with the current time range set, then all is good, no download and restart needed.
When no restart is required, it is not fingerprintable.
It causes a “Fingerprintable reaction  when big clock skew attack was used.”
“Network fingerprint: ISP can not guess which anonymity software is being used because of tordate ”
“No (bad), if clock is too much off when booting. ”
“Quoted from the Tails Design about Time syncing: “Our initial time guess based on the Tor consensus is probably easier to fingerprint, though: a fresh Tor is started, and restarted again right after the consensus has been downloaded.””
I don't see what's fingerprintable about this in our design where we have persistence for guard-data.
This would apply to first start of Whonix-Gateway because then we don't have a Tor consensus yet.
Also thinking through what would happen on computer reboot, when the host’s clock was modified (attack against NTP) or buggy would be required, since when VM starts, VM time = host time.
A suggestion is for consensus data to be fetched over Tor whenever possible else, fallback to clearnet.
It's a bootstrap problem and much different topic. A suggestion to be made for Tor, not Whonix. In summary, Tor clients need to know what the current Tor network is (=consensus) before they can use Tor. Related, see also: http://tor.stackexchange.com/questions/287/how-can-tor-use-a-one-hop-circuit-to-a-directory-server-during-initial-bootstrap