What do you do about a clock attack on VirtualBox? It must have been an attack carried out on the virtualizer because the time is off on a clone I made of the original also. I haven’t been using the original or updated it, so the alteration must have taken place in the virtualizer.
I tried restarting swdate. No effect. Clock still skewed.
I’ve read up about why not to use VPN as an alternative to bridges when tor access is blocked, but in my case VPN first is the only way to connect to tor. Can tor traffic be selectively throttled, bandwidth reduced? I guess I live in a totalitarian regime, not the US. Even with the correct clock on another system, the regime can block and reduce connectivity. What are they doing to obstruct tor?
Seconds and in exceptions even minutes? Expected for all users.
Hours? Not expected but that’s likely just confusion about the timezone being set to UTC in Whonix VMs.
Yes. Selective reduction or blocking various traffic types (such as for example voice over IP (VoIP)) is well known for at least more than a decade. Search term for search engines:
traffic shaping
As traffic passes through the ISP networks, the ISP has the capability to add layers such as IP based or DPI (deep package inspection) doing stuff such as prioritization, throttling or blocking.
There are various firewall providers offering technologies for blocking certain traffic or traffic shaping (throttling). Search terms perhaps “Cisco Firepower” or “barracuda traffic shaping”. This information doesn’t seem to be heavily advertised. Search results seem to be rather about censorship circumvention than companies advertising services to for blocking and traffic shaping. However, big ISPs certainly have the contacts and credentials to learn more. It’s also not rocket science for teams of developers to develop such technologies in-house.
There are also research papers available for analysis how it’s done on a technical basis. Interesting for sure but that doesn’t directly benefit users.
Note, Whonix builds “on top” of Tor. Whonix makes use of Tor.
Whonix doesn’t develop Tor.
Therefore all of this is unspecific to Whonix and this not the best place to ask as you might have noticed, there’s not a flood of highly diverse and super technical replies.
This is also called a network obstacle.
Whonix isn’t focused on censorship analysis or circumvention. So if this is your primary concern, you’re in the wrong place. Check this out:
Actually, you might be interested to know that this is a Whonix specific obstruction. I ran some tests. Sdwdate if off by several minutes in both the Gateway and Workstation. That must be enough to stop the connection because it does or there is an unknown factor. TBB runs fine on the host with unaltered, correct clock. Kicksecure in a virtualizer also can connect to tor. So the ISP is targeting Whonix OS specifically. Maybe something like a user agent changer that obfuscates Whonix as the OS would help. Whonix still works on other networks. So someone has developed a block for specifically Whonix or sdwdate.
Ooni detects a middlebox. Some of the most useful tests from M-Labs were retired like Neubot DASH or Glasnost.
It’s the second largest ISP in the US, so it would effect many people. I guess the gossip is that totalitarian local police persecuting the poor who have committed no crimes because of a very real caste system in the US can penetrate secure core international vpns and TBB but not Whonix, so they have to block Whonix specifically.
There are related questions in different topics but I think you are addressing the root cause with that statement. I will mention that after waiting a while and trying again, sdwdate synchronized to same minute as correct clock and then functionality significantly improved with only occasional disruptions. So the problem probably was interference with swdate through a middlebox traffic shaping. Then again, you are saying that the Tor network itself might have obstacles, which might impede both sdwdate and updates (brought up in topic elsewhere). The obstacle to tor updating is independent from the access point blocking sdwdate. So I should as Tor why updates are being blocked, not Whonix? I think this is the same phenomenon I was encountering a year ago with sdwdate on Qubes. There’s an obstacle in the Tor network? That Tor network obstacle might also explain how KVM downloads are disrupted (topic elsewhere also, but I think you have just pointed to the cause here if I am not mistaken).
hours: If time is off by hours, it’s more likely confusion caused by timezones. Whonix on purpose sets time to UTC. Hence, if you you compare it with the host which uses your local timezone it will be different. The minutes would be similar but hours could be different.
minutes: sdwdate has to acquire the time from somewhere. It acquires it from onion time sources. These are defined in file /etc/sdwdate.d/30_default.conf. It’s possible that some time sources are off by several minutes. Happened in the past. Would not be a shocker.
There’s an utility to check all onion sources but it’s supposed to be run by advanced users or developers since its output could be confusing:
/usr/share/sdwdate/onion-tester
It is conceivable that some ISPs might in theory specifically detect Whonix and only disrupt Whonix connections or use malware (viruses, trojan horses).
No? Obviously, I cannot prove a negative. I cannot prove this isn’t the case. This being conceivable is bad enough as the world is.
Yes? For now, I don’t see evidence for that.
However, this is speculation and jumping to conclusions based on limited technical skills. The technical skills required would be analyzing sdwdate in depth such as by looking at the time sources, understanding its logs and/or source code.
What this is more likely: Usability issues.
Please read this wiki page:
Not everything is plug and play. Instant, seamless perfection at all times doesn’t happen for most everyone. True. But also, not every reality satisfies Occam’s Razor. I would say that, actually, Linux GUI is very intuitive and user friendly. That’s true of Whonix, Fedora, Ubuntu, and TAILS at least. Those OSs are not much more complicated to use than Windows unless you doing customizations. It’s possible to get a lot more “sporty” in Linux.
The onion sources shouldn’t vary from user to user, would they? Then the question is, why is this happening to me. You suggest it must be user error. I say there is some external obstacle that has not been identified. You say that determining the cause requires expertise. No doubt. I just wish I could determine what it is. Whonix still works well on other networks, so it’s a non-stopper and just a matter of curiosity as to how that obstacle was created which if understood could increase the durability or tenacity of sdwdate and updates over tor.
I hypothesize that the Tor network can be manipulated. I served in the US Navy. I have friendamies that probably know exactly how to do that like a farmer knows how to irrigate ditches. They also know how to use Spectrum to blow your mind. Occam satisfactory? Plausibility depends on individual experience.
sdwdate picks 3 random onion sources. One from each pool. That explains the variance. If 1 onion source as a slow or fast clock, all users will be affected that happen to have selected that onion source by sdwdate.