On 12/19/2013 10:56 PM, Jacob Appelbaum wrote:
> 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... :(
This can be fixed upstream, in the kernel. The RFC says that the only
requirement is that the timestamps must be incremented, but says nothing
about the initial value. This will prevent the leak of the uptime.
>
>>
>> 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.
I agree with Jacob: I don't think Tails needs this features.
TCP timestamps are defined in [RFC
1323](
http://www.ietf.org/rfc/rfc1323.txt), entitled "TCP Extensions for
High Performance".
Timestamps are used for:
- "Protection Against Wrapped Sequence Numbers", but in our case, I
don't think that a "normal" Tails user could ever trigger a wrap,
because as said in [RFC 1700](
http://www.ietf.org/rfc/rfc1700.txt):
"The current recommended default time to live (TTL) for the Internet
Protocol (IP) [45,105] is 64.". A user would need to send roughly 2^32
packets in one minute.
- "Round-Trip Time Measurement", only useful when the user manage to
saturate the his connection. I don't think that the limiting factor for
transmission speed is the capacity of the user connection when using Tails.
I think timestamps can be safely disabled :)
>
>> 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
> _______________________________________________
> tails-dev mailing list
> tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
>
