tl;dr: Not anymore.
TCP Sequence number is a number which increments for every packet in a
TCP connection, to make sure TCP packets arrive in order.
A while back (~20 years) it was feasible to predict initial TCP sequence
numbers and spoof TCP packets, because they started at 0 or a fixed
value, but today the linux kernel has that patched and uses a random
value from a PRNG.
Linux 2.4.x includes time of day in the hash for the initial sequence
number:
seq = hashMD4(sourceIP + destinationIP + sourcePort + destinationPort +
timeOfDay)
see:
http://fxr.watson.org/fxr/source/drivers/char/random.c?v=linux-2.4.22#L2139
2.6.x uses an internal PRNG with many sources of entropy to generate the
initial sequence number and md4-hashes it with the IP and port to get
the initial sequence number:
seq = hashMD4(sourceIP + destinationIP + sourcePort + destinationPort +
getRandomBytes())
see:
http://lxr.free-electrons.com/source/drivers/char/random.c?v=2.6.30#L1562
3.x does the same, but with md5:
seq = hashMD5(sourceIP + destinationIP + sourcePort + destinationPort +
getRandomBytes())
see:
http://lxr.free-electrons.com/source/net/core/secure_seq.c?v=3.1#L104
2.4.x indeed leaks the clock in the hash and an attacker could guess the
local system time by bruteforcing. Hash-collisions would probably occur,
making the prediction unreliable.
2.6.x and up uses an internal PRNG, which also collects entropy outside
the attackers scope, like HDD delay. Guessing the clock via TCP Seq
numbers is impossible here, because the clock isn't even necessarly
included in the hashing.
2.6.0 was released 2003, it is highly unlikely you will find anything
below Linux 2.6.0 involved in the Tor network.
"But I read md4/md5 is insecure": Yes, but here it is just used to hash
things, not to make hashes collision resistant.
Once again we learn: Do not listen to Jacob Appelbaum, he lacks
technical understanding, can't properly research and repeats anecdotes
he read in a 20 year old whitepaper.
Looking back at the paper "An Improved Clock-skew Measurement Technique
for Revealing Hidden Services", only the measurement over HTTP headers
is left. Measuring HTTP time header, predicting the ambient temperature
from the HTTP time error and approximating the hidden service to a
geographical position by using the daily temperature curve sounds pretty
far fetched to me. We can't even reliably predict tomorrows weather.
Patrick Schleizer wrote:
> Hi!
>
> Is it possible to derive and/or estimate the system clock by observing
> TCP sequence numbers?
>
> Jacob Appelbaum [1]:
>> In the Linux kernel, TCP Sequence numbers embed the system clock and
> then hash it. Yet another way to leak the system clock to the network.
>
> As I understand the paper 'An Improved Clock-skew Measurement Technique
> for Revealing Hidden Services' [2] (6/23 = pdf page 3), it implies that
> TCP sequence numbers can leak the system clock.
>
>> Some clocks can be queried remotely:
>> Clock: TCP sequence numbers
>> Firewall: Cannot be blocked
>> Other: Linux specific, very difficult to use
>
> Is this the case or does that paper mean something else?
>
> On the other hand, I've read the claim "The kernel embeds the system
> time in microseconds in TCP connections.", but I haven't found the code
> in question to confirm, that this is so. Any idea?
>
> Was also recently raised on Tor's issue tracker. [3]
>
> More resources: [4] [5]
>
> Cheers,
> Patrick
>
> [1] https://twitter.com/ioerror/status/509159304323416064
> [2] http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf
> [3] https://trac.torproject.org/projects/tor/ticket/16659
> [4] http://lxr.free-electrons.com/source/net/ipv4/tcp_ipv4.c
> [5]
> http://stackoverflow.com/questions/12231623/initial-sequence-number-generation-in-linux-tcp-stack/12232126#12232126
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
>
