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@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.