Re: [tor-bugs] #16659 [- Select a component]: TCP Initial Sequence Numbers Leak Host Clock

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16659: TCP Initial Sequence Numbers Leak Host Clock
--------------------------------------+-----------------
     Reporter:  source                |      Owner:
         Type:  defect                |     Status:  new
     Priority:  normal                |  Milestone:
    Component:  - Select a component  |    Version:
   Resolution:                        |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |
--------------------------------------+-----------------

Comment (by source):

 >So patch your kernel? I'm not seeing why this is a Tor issue, beyond "if
 you switch to using a UDP based transport, this will be a non-issue".

 No one is saying it is one. I believe the goals of the TAILS, Whonix and
 Tor projects are aligned when researching and designing systems resistant
 to attack. Tor developer Jacob Appelbaum brought up the problem of TCP
 Timestamps on the TAILS mailing list and led to them disabling this
 feature. Its not a bug ticket but more of a research question. If it is a
 serious problem it could have far reaching consequences. Simply patching
 my kernel would make me stand out and not protect virtually every Linux
 system out there.


 >I think there is some confusion due to a recent tor-talk post that was
 stitched together based on a bunch of partial/incorrect/unrelated
 information and then ignored by reasonable people because tor-talk is
 ruled by trolls.

 I wasn't aware of this but I have nothing to do with it and I'm looking
 for answers from reputable and competent people aka you the Tor Project
 team.


 >Your Guard, or anyone that sits between you and your Guard knows who you
 are. Leaking the delta of a timer that is on a 274s period with 64 ns
 resolution doesn't seem like a big deal. Real time in ns is shifted,
 truncated, then added to a salted hash to derive the ISN, so it's not like
 it's possible to work backwards to the real time (or for that matter the
 original timer value) in any way, the best you can do is obtain load
 information via clock skew.

 But pages 10-12 in
 http://www.cl.cam.ac.uk/~sjm217/papers/ih05coverttcp.pdf seem to describe
 how to work backwards and get the original clock.

 If I'm not mistaken, the TCP ISN code here: http://lxr.free-
 electrons.com/source/net/core/secure_seq.c?v=3.16 suggests the time is
 added after the source/destination port and IP are hashed together with a
 secret.

 There is also the question of whether a 32bit salt is enough, if indeed
 the time is part of the hashed information - but it doesn't seem so.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16659#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs