[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Do NTP and TCP timestamps really leak your local time?

Whonix and many other people use this as a source when saying NTP leaks the local time:

RFC5905:

Origin Timestamp (org): Time at the client when the request departed for the server, in NTP timestamp format.

But this says the time is in NTP timestamp format which is epoch time. Epoch time is universal and the same on all systems so this isn’t a problem.

The kernel docs say this about TCP timestamps:

1: Enable timestamps as defined in RFC1323 and use random offset for each connection rather than only using the current time.

So, setting net.ipv4.tcp_timestamps to 1 wouldn’t leak your local time as it uses a random one.

Is there something I’m missing here or are these really not leaking the local time?

1 Like

NTP is not secure and besides it uses UDP (not functional over Tor) We have a lot of references explaining why it 's a bad thing.

for TCP timestamps see the reference also included in the page above:

https://mailman.boum.org/pipermail/tails-dev/2013-December/004520.html

1 Like

I know why NTP is a bad thing but I just want to know if it really does leak the local time.

The only reference about it leaking the local time was the one I talked about in the post.

I get a 404 with that link.

I also know TCP timestamps by default do leak your local time but Linux seems to prevent that by using a random offset.

1 Like

I found the commit that implemented the TCP timestamps random offset.

This was in 2016 and that link to the mailing list is from 2013 as indicated by the URL so they wouldn’t have known about this.

Maybe we should bring this to the Tails team and see what they have to say?

2 Likes

Sure, always feel free to start wider discussions across the ecosystem.
If it’s well researched like this, good might come out from it.

2 Likes

Epoch time isn’t actually the same on all systems. All systems follow the same format, but not at the exact same value hence it’s possible to track individual users with it.

I created an issue.

https://redmine.tails.boum.org/code/issues/17491

1 Like

I’ve re-read the discussion that lead to #6579 and I agree we should do this.

It would re-enable the “Round-Trip Time Measurement” TCP feature, which back then we thought was not needed in Tails because "the limiting factor for transmission speed is rarely the capacity of the user connection. In retrospect, I think this argument is quite weak: plenty of people on this planet have poor Internet connections that will be the limiting factor.

Implementation wise, reverting 32f216d18d6f5b8a5d7c5db2c2c031fb6eda2f85 and dd8cbeed76cfe922d6166aa0256b56215674a16e should do the job.

1 Like

What do we gain from re-enabling timestamps? We haven’t had a single complaint about perf in the years since.

1 Like

Round-trip time measurement and protection against wrapped sequence numbers.

https://tools.ietf.org/html/rfc1323

1 Like

Greetings,

but Linux seems to prevent that by using a random offset.

Please keep in mind that anonymity, the way it’s a concern in projects like Tor or Whonix, has not been and is not a concern for Linux kernel developers. You should be generally very careful when you interpret a patch or a code change as something that reinforces anonymity of the operating system because it’s usually not the case.

That said, lets take another look at the aforementioned patch:

Re-use of ISN generator also means timestamps are still monotonically
increasing for same connection quadruple, i.e. PAWS will still work.

Adding a per-connection/per-socket offset won’t resolve the issue as we see it. Such a random number will make timestamps in different connections look probably very different but they still monotonically increase by including a timer value and hence they are related to each other within a single connection. And if this is what happens (which most probably is) it means that, whatever causes the timers of the system to count a little faster or slower - like CPU load - can be visible in the sequence of timestamps in one connection. Further, experience has shown, exposing any unnecessary piece of information about the internals of your environment - like a timestamp- can make tracking simpler.
A lot of TCP features have been added for improving efficiency and when it comes to using systems like Whonix and Tor network, users should first agree about losing the luxury of high speed internet before using these systems.
For this specific case, I can’t confidently say that enabling timestamps can be good or bad without reading the code to see how it’s been implemented and how it works exactly but I’m almost sure, based on their description and a quick look at their variables and the places they’re accessed (which can be a little different in newer versions), the random offset will not make changes in the oscillator frequency invisible in the timestamps. So the problem should still persist and I don’t recommend enabling TCP timestamps.

4 Likes

@Sirus Thanks for the awesome feedback.

@madaidan please relay that info back to Tails because they are about to revert this privacy preserving measure because of your ticket.

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]