Situation:
-
On a GNU/Linux system running trusted Free Software, no information is leaked without the users consent. There are two caveats which are a result of misguided standards specs and design decisions.
-
The 2 known ways a host’s clock was/is leaked to the clearnet are through TLS handshakes made by software running on the host and and TCP connection made by default.
-
Recent work was made in this area due to more vigilance by privacy software engineers in the TorProject. At the moment work has been done by TPO member Nick to eliminate ssl timestamp leaks both in upstream crypto libraries OpenSSL and NSS (used in Firefox) and in the IETF standard itself that encouraged this harmful practice.
If unsure about the availability of this patch in one’s OS, as a workaround its best to simply not to connect to the clearnet from there. There are many compelling reasons not to do so out of a vm as discussed in my blog post.
However there are reasons where its still necessary to do so such as updating the system. This leaves one more leak open. -
This leaves the TCP timestamp which is enabled in the Linux kernel by default for some esoteric performance reasons. TCP timestamps serve to reveal how many unique devices are running behind a router, the uptime of the system and the host’s time down to the millisecond. Downright dangerous and unnecessary information.
The clock skew attack for deanonymization becomes a problem only if the adversary has the host’s clock time to compare to the one in the vm. If we deprive them from the former, that renders this attack useless.
At this point whether NTP is enabled or not on the host is irrelevant as a skew should not be readable. Whether a secure distributed torclock ever becomes a reality is far fetched and not needed if the underlying system is configured safely.
Recommendation:
Distribute a simple script that disables TCP timestamps for Linux host’s with the qcow2 images under a : “anonymity enhancements” directory.
References:
ietf.org/mail-archive/web/tls/current/msg09861.html
PROPOSAL 1:Declare that implementations MAY replace gmt_unix_time either with
four more random bytes, or four bytes of zeroes.Rationale:
Some implementations (like TorBrowser) are already doing this
in practice.It’s sensible and simple. Implementors are quite unlikely to
mess it up.
MAY in this context means not mandated as per the IETF draft and providing a zeroed out timestamp instead.
https://www.ietf.org/mail-archive/web/tls/current/msg10857.html
Sorry about my late reply. I am a programmer working on the NSS crypto libraries. While reviewing recent changes to NSS, I noticed that Nick's proposal 1 has been implemented in the OpenSSL and NSS source code repositories, which led me to this old email thread.
https://mailman.boum.org/pipermail/tails-dev/2013-December/004522.html
Yes. And due to a Tor issue (TLS itself), the absolute clock on the system is also leaked in the handshake. Nick has been working on fixing this - both in the IETF working group on TLS, in patches for OpenSSL and in other places, I think. When Nick finishes killing the gmt time leak in TLS, we'll still have one left in Tails: the TCP timestamp itself... :(