[tor-reports] [GSoC] wfpadtools: 3rd status report

[mjuarezm]

Hi all,

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.

Best,
--
marc