[tor-reports] [GSoC] wfpadtools: fifth status report

[Marc Juarez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

This is the 5th status report for the GSoC project. These last days I've
been struggling with a problem that has been annoying me for already
some weeks but I had not tackled until now because I had given to it low
priority.

The issue is that I observe TCP requests to the Pluggable Transport
client coming from the Tor client. Whenever the
'StaticDestinationServerFactory' listener receives a TCP connection, it
creates a new instance of the PT client and a new circuit which, at the
same time, induces the creation of a new PT server object downstream, at
the other end.

In the beginning I thought that this was due to some bug that I had
introduced myself but, after talking with George Kadianakis, it seems to
be the expected behavior of obfsproxy. This might be a major limitation
to implement wfpadtools in obfsproxy. In order to inject dummy messages
in a consistent way, I need all the traffic to be multiplexed in one
single stream.

This observation is however in contradiction with the Tor protocol
itself because between the Tor client and the bridge/entry guard there
is supposed to be a TLS connection. TCP traffic coming from the
application being tunneled through Tor is relayed over this TLS
connection. So, in theory TCP connections coming from the browser should
be already multiplexed at this point (PT client - PT server). Maybe I'm
missing something.

I cannot find the origin of the problem and it is really blocking me
because in my opinion this could be a fundamental flaw of wfpadtools.

Before getting into this I also worked in the following:

- - Modified wfpadtools protocol to be able to send control messages with
arguments that don't fit in the MTU (it spitts them in more than one
wfpadtool message): added a new field in the wfpadtools message header
and adapted message parser accordingly.

- - I also modified the shim observer in wfpad and wrote some tests for it
(http://goo.gl/5YCpS5).

- - As I said in the last report, for testing purposes I wrote a transport
wrapper for wfpad that dumps the state and all received messages into a
temp file (http://goo.gl/eAjGs2). To test a primitive, I simulate
sending a control message from the PT client (through a special message
that only the wrapper can speak) and load the dumps to check that they
correspond to the state I would get if running such primitive. Last week
I finished writing this wrapper and I already wrote tests for some
primitives. For example, for the primitive 'sendPadding(5, 0.1)' I
expect to see a control message from client to server and
5 padding messages delayed 0.1ms from the server to the client
(http://goo.gl/mlaRop).

- - Fixed a bug related to the stop condition at the wfpad base class
and wrote some documentation at beginning of the wfpad module.

Best,
- --
marc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT3C66AAoJEGfJ5xfgazlxbPUH/jVg1DdKluT3bgPkMUODaEPe
eiXQyLLsN2FnIc0atAfmjOTsX2A1rGsWrGXbjEZ2KqkubAbDda6XGhcoFrpF9bkA
BetACZ33j1QCtBbQTg5TpbIE5PjlPSmXQvbINx5EJ/9xWqD812eaR/0T3Ov5nAEh
div6RCyqNAe+fqkVzC+Hs9mISFHEfOKM6kwt3sOwbgZipcAEQCsuv0hU4qhaR1/Q
QGPeDojZG65+7/Rdo5blp2oTh2Q6HOFxc6Pcv1voAPjkTkEF8Cu9E2ilrSxbYN6B
0TvoLAUsRPc4TlPyyumL7xNIpVQHIM7nlWPU/Dee2Jw2cPb2571mn/OzWt3Z0Yg=
=j6GE
-----END PGP SIGNATURE-----