Off-topic: I am interested to move discussions to the next level. Many comments are just questions, that aren't clear in the original proposal. Or something is missing the the original proposal, that can be fixed. So I was wondering, if one (me) could make some comments, and then you improve the original proposal. If these comments are covered and no dissent, the previous discussion can be deleted.
Thank you for being open-minded about this and willing to hear more. The only reason I’ve reopened this discussion is I’m confident that there is something new on this. I will re-post the last conclusion i reached and start speaking from that position:
Actually you know what I think that anondate makes sense only on the workstation. the gateway doesn't need sdwdate/anondate. Sorry for the confusion, I'm sharing my thoughts as they develop. There are two main points being discussed.
anondate (can be safely used as the only trusted source) making it a great backstop in the event there is something on the workstation leaking timestamps and also on the host doing that as well. The security pitfalls of using it in the previous design, are avoided by rethinking how and on which vm its used on.
The gateway isn't leaking anything by using only the host's time to bootstrap off of as recommended. No danger in using the Host's time. If we decide to allow it to read the host's wall clock, then no gateway restart will even be needed because time is always synced and not allowed to drift. anondate or any form of timesyncing would not be needed on the gateway anymore. And the only place where it being used (the workstation) will have a trusted source with fresh data being fetched at all times with none of the fingerprinting or stale data attack implications that sending requests in the clear entailed: like the gateway design problems you pointed out before.</blockquote>
user <-> Tor network <-> Tor exit <-> ISP of Tor exit <-> ISP of destination server <-> destination server
If you keep changing Tor exit's, you make a mitm only less likely for a fraction of that route. Marking the by:
Alright so in the situation that anondate is depended on for use in just the workstation, the damage the attacker can do by feeding outdated consensus is limited to getting a false time. It would not affect or deny service to the gateway in any form.
As in the current model of the sdwdate, getting a consensus on the consensus data (pardon the pun) curbs the damage an attacker does, because a certain time interval is not used unless, say, some number of requests X out of Y total to a Directory Authority agrees.
Come to think of it, these traffic requests by anondate are actually not distinguishable any more from any Tor client out there.
The fact that the gateway is using accurate host time, means that no problems with connections to the Hidden Service server will happen.
By the way, don't trash sdwdate too fast. When we implement a host operating system or Whonix host additions (https://github.com/Whonix/Whonix/issues/39), we're back at the question on how to safely replace unauthenticated NTP. Not sure how much this changes your proposal.
I’m sorry if I had given you that impression. It is not my intention to trash it and given the amount of effort you’ve taken in designing and maintaining it, I should have made that more clear in my comments. I am examining the current Whonix design in light of recent developments (for example disabled Timestamps) and what they allow us to improve.
Set clock from verified Tor consensus only or also from unverified Tor consensus?
When only using verified Tor consensus, there is only a limited amount of replay attacks a mitm could do. Because only a limited amount of Tor consensus that have ever been signed.
Verified only, there is no reason to do otherwise.
How many different verified Tor consensus documents has a mitm at it's disposal? It's renewed every few hours and replaying is possible for months. And each consensus contains different date/time. I am wondering what would happen if a mitm in position of the directory authority's ISP would make a different replay attack (sending a different version of Tor consensus) for each and every request. If that could be used to single out users somehow.
We can use a sample size of 5-10, or something similar to the number of requests sdwdate makes at the moment. They may differ but there is a certain widely agreed upon range at any given time. We can calibrate against this range and set it somewhere in the middle of the average of all values fetched. The solution to avoiding bad ISPs is to diversify connection to Directory Authorities through different circuits/exit nodes.
For your Whonix Host implementation, its best to ship it with NTP disabled and no time syncing mechanism. No before you dismiss it, here’s why:
Computer BIOSs keep track of time across reboots by having their own internal clock. That allows all computers to keep track of time across reboots instead of resetting them.
A timesyncing mechanism is not really needed. All we care about is that the host time is set roughly accurate enough (manually if needed) to enable Tor to connect.
A time syncing mechanism on the host entails a risk of remote attack if its using anything.
anondate on the host is not needed and would probably have more cons than pros: allowing a local ISP-level adversary to influence time.
Consider this situation: Whonix Host is being used to communicate with the clearnet and a user runs software with some obscure protocol that leaks time on the Host and in the workstation. here’s what happens if we have Whonix vms setup in a (Whonix host no timesync & NTP disabled, gateway uses kvmclock, workstation uses anondate):
The gateway can connect to Tor with no problems. It doesn’t leak anything and so it doesn’t need a timesyncing mechanism.
Anondate on the workstation prevents a user from shooting themselves in the foot when running software in the manner discussed above as the Guest’s time is set differently than the host’s
From Whonix Host perspective: No denial of service attack on Tor due to an outdated consensus fed, no preplay attacks either. No remote exploit of any timesyncing client whether secure or not.