“sudo echo 0 > /proc/sys/net/ipv4/tcp_timestamps” alone isn’t good advice. Does not survive reboot. And it’s already documented here:
Why duplicate it?
And if we wanted duplicates, we should use templates to avoid a delta.
To mitigate TCP ISNs you must avoid sending any traffic clearnet.
In that context... How is that possible? Tor traffic itself uses TCP. I am not talking about what's inside the Tor streams. Talking about a Tor client's own connections to Tor relays [or bridges]. Such as the initial connection handshake. Tor uses the operating systems's usual routines for that, hence the kernel's TCP, hence TCP ISNs will leak. Not?
Its based on the incorrect advice I saw in the reference website. I didn’t know you had it documented somewhere else, its hard to keep track of the places to look at the moment until the opsec information put all in one place. I think if its best that we keep all Time related settings on Time Attacks and link to it from Pre-Install advice since there is more to do. I don’t want to include Windows advice because there are so many things that leak timestamps and there is no way to control them that it won’t really matter. Also the mitigation section on my page is focused exclusively on GNU/Linux hosts.
What makes you think, that Tor does not use normal TCP for it’s own connections, that it uses special TCP sequence numbers? You can use wireshark. Disable relative TCP sequence numbers (usability feature). Let it show the real TCP sequence numbers. (TCP_Relative_Sequence_Numbers)
Application-level traffic: Unlike privacy software developed by the Tor Project, internet-facing applications can leak clock information in their traffic. For example JS in browsers and timestamps in emails.
This implies, that TorBirdy is not affected by this issue. But it is.
https://www.whonix.org/wiki/Dev/TimeSync#Local_Clock_Leaks
Not sure about you plans with that page. Don’t want to break it just yet. Consider the following.
=== Design Goals ===
* All clocks, the host's, Whonix-Gateway's and Whonix-Workstation's should slightly differ. <ref>So those cannot be linked.</ref>
* Secure end-to-end encryptions.
* Distributed trust. <ref>Not giving too much value to a single remote time source.</ref>
* Smooth clock adjudication. <ref>No clock jumps.</ref>
Yes there are problems with Torbirdy at the moment but removing timestamps is a design goal. TPO resources are finite and hacking on Torbirdy is slower than TBB. This detail can be added if you feel its necessary.
prevent leak via Date header field (local timestamp disclosure):
On October 24th, 2014 sukhbir said:
The timestamp disclosures are via the date and the message-ID headers (relevant tickets: #6314, #6315). We have submitted patches to Mozilla (902573, 902580) that have not yet been merged. The patches probably need more work and we are looking for volunteers to work on them and help us to get them merged. We will be doing a blog post about this soon and put out a call for help.
Feel free to add more or better describe sdwdate of course.
I want Time Attacks to be about all the clock leak attacks and solutions. - including tools like sdwdate. This information can be deprecated to tidy up dev/timesync.
I consider dev pages to be more like space to make scratch notes about design decisions for developers rather than something for users/regular readers.
[quote=“HulaHoop, post:7, topic:1260”]I want Time Attacks to be about all the clock leak attacks and solutions. - including tools like sdwdate. This information can be deprecated to tidy up dev/timesync.
I consider dev pages to be more like space to make scratch notes about design decisions for developers rather than something for users/regular readers.[/quote]
Alright. Good distinction. I add to Dev/TimeSync then.
Consider the following.