[tor-bugs] #10598 [Obfsproxy]: Merge ScrambleSuit v2014.01.a.

[Tor Bug Tracker & Wiki]

#10598: Merge ScrambleSuit v2014.01.a.
-----------------------------+-----------------------------------------
     Reporter:  phw          |      Owner:  asn
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Obfsproxy    |    Version:
   Resolution:               |   Keywords:  pt, obfsproxy, scramblesuit
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------------------------------

Comment (by asn):

 Replying to [comment:7 phw]:
 > Replying to [comment:6 asn]:
 > > Replying to [comment:5 phw]:
 > > > Another thing which just came to mind: Do we want to use inter-
 arrival time obfuscation or not?  Right now, it is activated (see
 `USE_IAT_OBFUSCATION` in const.py).  While throughput it still reasonable,
 we can maximise it by completely disabling inter-arrival time obfuscation.
 That might not be a bad choice as timing-based attacks seem to be an
 exotic threat at this point.  Activating it at a later point in time is a
 matter of simply setting the above variable to `True`.
 > >
 > > I guess keeping it disabled for now makes sense.
 >
 > Agreed.
 >
 > > Maybe we should add an optional CLI/managed-mode switch to
 scramblesuit that enables it if it's needed? So that clients can enable it
 dynamically if it's needed by editing their torrc.
 >
 > Hmm, I'm not quite convinced that we should expose these internals to
 the user.  If it ever becomes necessary, we can just update our bundles
 with the option enabled.
 >
 > > Still looking forward to your Windows testing :3
 >
 > I just got around to testing it on a 64-bit Windows 7.  It seems to
 work.  I tested it using Python 2.7 in external mode (is it reasonable to
 infer that it will also work in managed mode?).  I also noticed that we
 now need the module `pyyaml` which I added to `setup.py`. I also updated
 `ChangeLog`.
 >

 Yes, I guess your testing should be sufficient.

 You might also want to test starting up the listeners in managed mode in
 Windows. You can do that by using the following environment variables:
 {{{
 export TOR_PT_STATE_LOCATION="/pt_stat"
 export TOR_PT_MANAGED_TRANSPORT_VER="1"
 export TOR_PT_CLIENT_TRANSPORTS="scramblesuit"
 }}}

 {{{
 export TOR_PT_STATE_LOCATION="/"
 export TOR_PT_MANAGED_TRANSPORT_VER="1"
 export TOR_PT_EXTENDED_SERVER_PORT=
 export TOR_PT_ORPORT="127.0.0.1:9001"
 export TOR_PT_SERVER_BINDADDR="scramblesuit-127.0.0.1:8000"
 export TOR_PT_SERVER_TRANSPORTS="scramblesuit"
 }}}

 The first are for the client, the second are for the server case. Put them
 in a file (say `test_managed_client.sh`) and do `source
 test_managed_client.sh`. Then run `obfsproxy --log-min-severity=debug
 --log-file=fun managed` and check whether the listener was started and if
 the logs have anything weird. Starting up both listeners in managed mode
 should give us some more confidence that it works well on Windows.

 > I pushed a new branch:
 https://gitweb.torproject.org/user/phw/obfsproxy.git/shortlog/refs/heads/scramblesuit_integration-3

 I think this last branch `scramblesuit_integration-3` does not contain the
 scramblesuit docs in the `/doc` directory.

 I will add them and merge the whole branch to obfsproxy Real Soon Now
 (today or tomorrow).

 Cheers!

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