disable leaking TCP timestamps by default

[adrelanos]

Use cases:

• Security general: you want to hide the exact state of your local clock from outside observers for cryptographic purposes.
• Anonymity. Avoiding correlation. Time leaking from the non-anonymous connection being linked with local clock leaks from torified VMs. (The torified VMs are not necessarily whonix-ws TemplateVM based. They may not necessarily run sdwdate. So this is nice as defense in depth.)

We have this in Whonix documentation, disable TCP timestamps. [And we have a deb package tcp-timestamps-disable for that.] But who knows what fraction of users reads and applies these steps. This is something worth being automated and/or applied by default.

Implementation wise, this would be very simple. In the NetVM (at least, nevermind others), shipping a file /etc/sysctl.d/30_tcp_timestamps.conf with the content:

net.ipv4.tcp_timestamps = 0

(Plus perhaps explanatory comments / license.)

There may also be disadvantages by disabling TCP timestamps. Judging if/how theoretical/practical those are is up to you.

(Please don't name the file exactly /etc/sysctl.d/tcp_timestamps.conf - that would conflict with the tcp-timestaps-disable package.)

If this simple implementation sounds alright to you, I could create a pull request.

(There is also an related issue, disabling ICMP timestamps. But that's a separate issue. I'll open one if/once we found consensus on how to proceed on this one. Specifically if it's alright to just apply this setting for everyone by default, which is the simplest, implementation wise.)

[qubesuser]

Doesn't this also disable the beneficial effects of having timestamps outlined in RFC 1323? Is that an issue?

Maybe using something like a monotonic real time clock (so that uptime is not leaked) limited to 10-1000ms resolution could be better?

Also, I think this needs to be done for all VMs not behind Tor (or another TCP proxy), since routing just passes the timestamps through, right?

[qubesuser]

Doesn't this also disable the beneficial effects of having timestamps outlined in RFC 1323? Is that an issue?

Maybe using something like a monotonic real time clock (so that uptime is not leaked) limited to 10-1000ms resolution could be better?

Also, I think this needs to be done for all VMs not behind Tor (or another TCP proxy), since routing just passes the timestamps through, right?

[adrelanos]

Yes, it has to be done for all VMs. Not just torified ones.

[adrelanos]

Yes, it has to be done for all VMs. Not just torified ones.

[marmarek]

Reading RFC 7323 (which obsoletes 1323) gives me impression that TCP
timestamps are mostly useful for really high bandwidth and large latency
connections. And even then, not having TCP timestamps "only" reduces
performance.
I think we can disable it by default. If for some rare cases the impact
would be too big, user always can re-enable it.

Changing it to something else ("monotonic real time clock limited to
10-1000ms resolution") is not an option, unless done in upstream kernel.
And probably also something outside of our skill set...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Reading RFC 7323 (which obsoletes 1323) gives me impression that TCP
timestamps are mostly useful for really high bandwidth and large latency
connections. And even then, not having TCP timestamps "only" reduces
performance.
I think we can disable it by default. If for some rare cases the impact
would be too big, user always can re-enable it.

Changing it to something else ("monotonic real time clock limited to
10-1000ms resolution") is not an option, unless done in upstream kernel.
And probably also something outside of our skill set...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Do you want this backported to R3.0?

[marmarek]

Do you want this backported to R3.0?

[adrelanos]

No need for backport. As long as #1346 isn't implemented also, which we - as I would guess - cannot backport, this alone isn't that useful.

[adrelanos]

No need for backport. As long as #1346 isn't implemented also, which we - as I would guess - cannot backport, this alone isn't that useful.