[tor-reports] [GSoC] wfpadtools: 3rd status report
Marc.JuarezMiro at esat.kuleuven.be
Fri Jul 4 20:33:42 UTC 2014
This is the third GSoC report of the “Framework for Website
Fingerprinting Countermeasures” project. This last week I attended the
summer Tor-dev meeting and had discussions with my mentors about the
project. These talks helped me to better understand how they envision
this new PT.
* One of the outcomes of these discussions were several design decisions
that may change a bit the structure of the PT. I was reusing part of the
Scramblesuit’s logic to sample packet lengths and delays. The idea would
be to drop this in favour of the implementation of a set of primitives
(which we assume to generate the space of WF defenses) that Mike Perry
proposed and introduced in one of the sessions of the meeting. These
primitives would allow constant-rate padding, Scramblesuit’s
functionality, and other padding strategies that have been proposed in
the WF literature. One of my TODOs would be to reimplement BuFLO using
these primitives instead of Scramblesuit’s.
* I have been working in the implementaion of a new type of WFPad
protocol message (in these lines you can find a very short spec:
http://bit.ly/1xqjbTx). The type is specified using a new flag called
FLAG_CONTROL and including in the header two new fields that contain the
operation code and arguments related to a specific primitive. These
messages would also piggyback Tor data.
* The initial idea was to prototype the framework in a PT keeping in
mind that in the end it would be implemented in Tor’s core. However,
given the amount of effort required to do this properly, Yawning
proposed to orient this PT to research purposes for now. So that we can
start playing with possible defenses as soon as possible.
* Yawning also implemented a shim that acts as a proxy between the SOCKS
server and Tor that intercepts the SOCKS requests. This provides enough
framing info to the PT so that we can infer when a session (i.e., a
visit to a page) starts or ends. However, there seems to be a bug
somewhere because we observe that a new instance of the PT is created
for each TCP connection. I'll try to spot the origin of this bug.
* I've been also working in the tests and refactoring code.
More information about the tor-reports