I am not a fan of NTP’s unauthenticated nature and inability to work over Tor, but I am sure it’s already the apocalypse. In this thread I would like to discuss how much it can be skewed.
Added a source and made some calculations here:
Please check.
Looks good.
AFAIK this can be extrapolated from similar siutationss: Because it lacks encryption and authentication, an attacker could MITM the request, impersonate an NTP server and potentially tell any lie they like to the clock. A replay attck could skew the clock so much that it could fall in a range that makes Tor fail to connect.
Would take quite a long time to make this attack work. While not super critical, it should be solved. I know by experience that many users simply ignore if their system clocks are wrong.
Would take quite a long time to make this attack work. While not super critical, it should be solved. I know by experience that many users simply ignore if their system clocks are wrong.
Yes but there is literally no benefit of having NTP running. Disabling it isn’t that hard and should be documented in the security guide IMO.
I am not so sure about that. You instantly join the small group of users that do not use NTP.
Know about the leap second already?
Why did they about implementing NTP in the first place?
Why did all operating systems bother installing it by default?
What are the consequences of the clock drift that will inevitably result from this?
How much does a usual hardware clock drift per day, month, etc?
How much does defect hardware clock drift per day, month, etc?
Yeah, maybe a giant nag screen to ask the user once to check its system clock and relying from then on hardware clock only may work. But as I know users, they don’t care about defect hardware clocks that are far off. We need to be really careful with decisions as this one. Can’t act on assumptions.
Thats similar to the y2k scare a few years back but I’m not sure how turning NTP would make the sky fall.
Systems don’t have to have it on and if nothing leaks the time then no one will know you don’t have it on.
Maybe nothing happens. But I think these are valid questions. And we should act on knowledge/certainty, not on probable assumptions.
ISP knows whether it’s in use or not. Because they either see NTP traffic or they don’t.
Maybe nothing happens. But I think these are valid questions. And we should act on knowledge/certainty, not on probable assumptions.
AFAIK this leap second bug was caused by a kernel bug, nothing NTP could have done to fix this.
ISP knows whether it's in use or not. Because they either see NTP traffic or they don't.
Most people are behind routers. The way DPI distinguishes individual machines behind a router is through tracking TCP time leaks.
When there are TAILS users, the traffic will not have TCP timestamps, so should this dangerous information be left to leak so traffic is not marked for that? I don’t think so.
I’m not pushing for this. If you don’t want to recommend it its ok.
AFAIK this leap second bug was caused by a kernel bug, nothing NTP could have done to fix this.[quote]Maybe nothing happens. But I think these are valid questions. And we should act on knowledge/certainty, not on probable assumptions.[/quote][/quote]
Yes, NTP would not have helped. I just wanted to show that small things like “just a second” can have broader consequences nevertheless.
If you don't want to recommend it its ok.It's hard for me to recommend things, if I don't fully understand them. It would be okay to present the current state of knowledge and research, which is that there are open questions as per: https://www.whonix.org/forum/index.php/topic,512.msg3945.html#msg3945
When there are TAILS users, the traffic will not have TCP timestamps, so should this dangerous information be left to leak so traffic is not marked for that? I don't think so.Leaving them enabled seems the worse than being fingerprintable. An better solution may be be something like SkewMask.
See also:
https://labs.riseup.net/code/issues/5773
“What kind of fingerprinting resistance a system like Tails can reasonably pretend to, at the network scale?” was the only question before they updated the ticket. It’s a hard question. The fingerprinting stuff is an arms race. As well as a rabbit hole.
-We can either have a secure or non-fingerprintable time syncing system. Pick one.
-The lack of NTP is not that unique I’m sure people running Tor on transparent proxy mode on their phones and hosts don’t have NTP traffic too.
-The danger of having time leaks is much greater than being fingerprinted for not having them IMO. One can reveal your HS while the other just gives signs that you may be running a relatively uncommon setup.
Can also be combined, but then it’s becoming super complicated:
https://labs.riseup.net/code/issues/5773
-The lack of NTP is not that unique I'm sure people running Tor on transparent proxy mode on their phones and hosts don't have NTP traffic too.Just a transparent proxy alone isn't a great idea in many situations anyway.
I guess Android really doesn’t use NTP, because those clocks are synced by the carrier network.
One can reveal your HS while the other just gives signs that you may be running a relatively uncommon setup.This is a good argument to make fingerprinting a low priority. That stuff isn't binary 1 or 0. An arms race. At the moment censors work on detecting traffic flows and The Tor Project and devs are coming up with clever pluggable transports. When at some day things like "no Y (ex: NTP), but should be, probably X" are done by censors, hopefully there will be a separate team to create a fake operating system that emits the expected fingerprint.