intrigeri:
> Hi,
>
> it was brought to our attention (thanks Jacob!) that TCP timestamps
> (net.ipv4.tcp_timestamps) are enabled in Tails, and this might be
> a problem.
>
No problem. Glad to help, if it is actually helpful!
> In a nutshell, we're said that the risks that go with the current
> setting are:
>
> 1. The system uptime can be inferred from this information.
>
That is correct.
> 2. The system clock can be tracked down to the millisecond.
That is also correct.
>
> As far as I understand it, in the context of Tails, this can be done
> by an attacker who monitors the network somewhere between the attacked
> Tails system and the Tor entry nodes being used. Right?
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... :(
>
> I must admit that I did not look closely enough, so in what follows,
> I'm assuming that this information is not forwarded by the three Tor
> hops to the other side of the connection. Please correct me if
> I'm wrong.
>
> Given such an attacker anyway knows the public IP used by the attacked
> system, I don't really get why Jacob calls this a "Major privacy info
> leak". May you please clarify what exact threat you have in mind?
>
I think the inverse issue is important to consider: look for clocks that
match an expected value to _find_ the public IP used by a user.
> Off the top of my head, I can think of:
>
> a. Finding out how long a given Tails system has been running: if an
> attacker in this position got to watch the network (close enough
> to the attacked system) when it was bootstrapping Tor, then they
> can learn this too. I'm not overly concerned by this threat.
>
There are currently two ways to do this that come to mind - one is by
watching Tails traffic (first bootstrap, etc), the other is by looking
at every TCP connection setup. This also ensures that non-Tails clients
or different Tails clients behind a NAT will be distinguishable. It
would be nice if a network of Tails machines behind a NAT looked like a
single Tails machine other than the bootstrapping phase.
> b. Distinguishing several Tails systems running behind NAT and using
> the same IP address: I would call this a minor issue, and the
> same reasoning as in (a) applies.
>
If there are four Tails clients behind a NAT, an attacker can probably
distinguish them by TCP timestamp alone.
> A very quick web search seems to indicate that disabling TCP
> timestamps brings its own share of issues: first, disabling TCP
> timestamps also disables the TCP protection against wrapped sequence
> numbers mechanism; second, TCP timestamps seem to be a pretty useful
> performance feature of TCP.
Do we need those features? I would prefer to not leak anything about the
system at all. Currently, to recap: we leak the full clock and then
millisecond offsets. This allows for unique tracking across the internet
as well as unique host counting behind a NAT or similar networks that
proxy traffic in various ways.
> That's why I am reluctant to disable this feature without knowing what
> exact problem we would solve. I'm all ears :)
We'll make it harder to count Tails users behind a NAT, we'll make it so
that Tails users who sleep their machines won't be tracked across
networks, we'll make Nick's removal of gmt time from TLS complete for
the Tails picture, and we'll remove a general side channel.
All the best,
Jacob
