[tor-dev] wfpadtools: comments about primitives

Fri May 30 18:40:07 UTC 2014

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

Hi George,

Thanks for your comments.

On 05/30/2014 06:42 PM, George Kadianakis wrote:
> Marc Juarez <Marc.JuarezMiro at esat.kuleuven.be> writes:
> 
>> Hi all,
>>
>> I am a GSoC student working in a new PT for the development of future
>> Website Fingerprinting countermeasures in Tor.
>>
>> The PT is not targeting any specific defense, but to link padding
>> defenses in general. The idea is to implement a set of primitives that
>> any link padding-based defense would benefit of.
>>
>> In this email I provide a more detailed description of these primitives
>> and give a short update about their state. I forked the obfsproxy repo
>> and made it publicly available in bitbucket:
>>
>> https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools.
>>
>> I would appreciate comments from the Tor development community. I'm
>> specially looking for advices that help me generalizing the padding
>> module (padutils) and comments about the primitives I describe below.
>>
>> The envisaged primitives are:
>>
>> 1. A general padding class that provides methods to pad the link
>>
>> This part is almost finished. For that I reused the Scramblesuit's
>> probdist and fifobuffer modules to buffer and flush data according to a
>> given probability distribution.
>>
>> Using this class I have implemented a simple version of BuFLO (which is
>> also included in the padutils module).
>>
> 
> Sounds reasonable.
> 
> (BTW, we recently found that scramblesuit's genDistribution() function
> in probdist.py does not generate a uniform distribution. You can see
> this, since the way the prob distr is generated, its first element has
> a mean value of 1/2 instead of 1/n. Yawning fixed this in obfs4 I
> think, but it remains unfixed in scramblesuit.)

Oh, I see. That's why this module is not being used anywhere in
obfsproxy. Thanks for letting me know.

> 
>> 2. Create a framing layer for the PT
>>
>> This layer would allows to signal padding messages so that they can be
>> filtered out. I have to implement the protocol's message scheme so I can
>> parse the flags in the header and get rid of the padding messages.
>>
> 
> OK. You might want to write a small spec for your framing layer.

Yes, I have some diagrams for the message structure. Right now it's
pretty simple, I just have a flag that indicates whether a message is
padding or not. Though I think this structure will evolve a lot.

> 
>> 3. Implement the state machine of the basic padding protocol.
>>
>> BuFLO assumes that there exists a mechanism to detect the beginning and
>> end visits. I would implement this using a new state in the protocol's
>> state machine (ST_VISITING), but I still need to find a way to signal
>> the beginning and the end of each visit.
>>
> 
> Hm, by 'visit' you mean website visits? So your PT needs to know when
> you change websites? This is not supported at the moment. You can't
> even learn this information from within Tor, which is one layer closer
> to the browser than the PT.
> 
> Why does BuFLO need to know about individual visits?
> 
> Making PTs aware of website visits will require non-trivial changes to
> little-t-tor (and possibly implementation of proposal 196, etc.)

Yes, visits to webpages. I guess BuFLO does so to reduce the bandwidth
overhead. In BuFLO there is also specified the minimum time for which we
need to run the padding. This was directed to hide the real size of the
page in case it is unusually small. However, when the page is
sufficiently large to exceed the minimum time, it leaks information
about the real size, and it has been shown that this can be exploited by
an attacker.

I have to think more about it but we might not need the limits of the
visit. One possible approach could be to just fuzz these "page load
boundaries" by looking at the bandwidth loads.

>> 4. Implement the protocol's handshake.
>>
>> I took a look to the Scramblesuit's handshake.The handshake of this
>> protocol would boil down to the negotiation of the parameters (e.g.,
>> probability distributions) for the padding.
>>
> 
> In the end, I think this handshake will need to be confidential
> (encrypted) somehow. Otherwise, the adversary could read the
> probability distributions and unwrap your padding layer more
> easily. Or is this not in your threat model?

Yes, you're right. However, I think we shouldn't overlap too much with
Scramblesuit. I was thinking that Scramblesuit or obfs3 could be used
together with this PT. Actually this is a question I wanted to ask you:
can multiple PTs be used together? Except for the overhead of the
protocol headers I don't see any technical limitation.

> 
>> 5. Implement a flow control protocol
>> 	
>> This would adjust the padding parameters while running. The fifobuffer
>> we are currently using helps queuing the messages but we will need an
>> extra logic to detect congestion.
>>
>> 6. Padding operations
>>
>> We will implement padding operations that might be handy for the future
>> countermeasure. For example, one possible operation could be to specify
>> the number of cells to send in response to a padding cell request.
>>
>> 7. A module to test protection against Website Fingerprinting
>>
>> This module would leverage the Peekaboo's framework by Dyer et al. (we
>> may consider to extend it to include the newest Website Fingerprinting
>> attacks).
>>
>> Best,
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTiNCHAAoJEGfJ5xfgazlxjYAH/297fIPaIaifZBimXbew6byh
9rImZPTiWv2r6bGTLKrAEQoipZ9W+1Sv62XLsT39szNBziZgv5lFIWZFd0L+2zDg
9PpLIsxsk/JuKBc/Di+WYnNgVaFcmZR3lkoOwnT73zjc34p/DmuQZXJfSqDCTiRj
8Tk36r287YhePNLUkeaegjAEjUphUG1Bouf5aSJO4kCWf1nIbos/OpJ212/HW3QV
7UPMV17XOtpai01B7WDhPs9e0LIf1AvoxZMH6X20ibOnOqpf1L4izGMYyGIQufvY
xxoWQVxsha3kwmKJoQb3qRNMYs0UY/xLijYOPuofIPBqpFi5pV19CykKDPWU3CA=
=OpDS
-----END PGP SIGNATURE-----