[tor-bugs] #16659 [- Select a component]: Linux TCP Initial Sequence Numbers may aid correlation (was: TCP Initial Sequence Numbers Leak Host Clock)

[Tor Bug Tracker & Wiki]

#16659: Linux TCP Initial Sequence Numbers may aid correlation
--------------------------------------+--------------------
     Reporter:  source                |      Owner:
         Type:  defect                |     Status:  closed
     Priority:  normal                |  Milestone:
    Component:  - Select a component  |    Version:
   Resolution:  not a bug             |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |
--------------------------------------+--------------------

Comment (by mikeperry):

 Ok - ignoring MD5, here is the scenario where this might matter: In about
 1 in every sqrt(65535)==256 connections to your guard node, your tuples
 will replay, and the adversary will see this as well. In that case, they
 know the argument to seq_scale in http://lxr.free-
 electrons.com/source/net/core/secure_seq.c?v=3.16#L26 has replayed, and
 can then use this replay to extract 32 bits of your clock.

 Then, on the application layer (at the exit or hidden service) a clock
 leak can be used to aid correlation.

 Since Tor latency is on the order of a second, this probably gives about 8
 bits of information to aid correlation, though in practice it is probably
 less than that because most people tend to be using NTP and other network
 time syncs. Those that aren't however, will be in really bad shape against
 this attack.

 Concerning. Maybe is a bug after all. But again, we're not exactly on
 strong footing to land a kernel patch here. We'd have better luck making
 an ISN prediction argument, I bet.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16659#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online