[tor-dev] Website Fingerprinting Defense via Traffic Splitting

[Daniel Forster]

On Jan 7, 2015, at 9:13 PM, Mike Perry <mikeperry at torproject.org> wrote:

> I think regardless of our current entry guard choice (which is governed
> by the consensus and subject to relatively easy change, btw), having a
> datapoint on how traffic splitting affects Website Traffic
> Fingerprinting accuracy would be a very useful research contribution.
> 
> I am in general very concerned that basically one research paper caused
> us to make a decision to switch to a single, long-lived guard, and that
> a core assumption underlying this research paper is that traffic
> correlation is always perfect. Research that can at least shine some
> light on the actual tradeoff we made here seems generally useful and
> important.

Okay, this is enough motivation. My concerns were small though, but I
liked to ask beforehand..

> 
> 
> One thing I would ask is that for this particular piece of research, you
> also investigate the accuracy of an adversary that gets to see both
> links, but externally (ie a censoring/surveilling national firewall). I
> suspect that for such adversaries, there won't be much benefit from just
> splitting by itself, but we may end up surprised by how splitting and
> padding interact together with conflux-style load balancing. There may
> be emergent effects there that further complicate the attack, even for a
> local observer such as this.
> 

Yes, of course! We feel like this too, and we will evaluate the effect of the
system when the adversary is able to see and merge the mutliple streams.

> Hopefully you are also aware of our attempts to prototype padding
> defenses to the first hop using pluggable transports. See in
> particular:
> https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/ideas/xxx-multihop-padding-primitives.txt?h=multihop-padding-primitives
> https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/ and
> https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html
> 
> Perhaps you could save some implementation effort by laying these
> pluggable transports on top of a native tor splitting/conflux mechanism?
> 
> You may also be able to collaborate with Marc Juarez in other aspects of
> this research, too. There's a lot to study here, I think.
> 
> 
> -- 
> Mike Perry

Thanks for the pointers, I wasn't aware of all of them. And yes,
the plan is to implement the splitting part and then use pluggable transports
for the padding part.

Daniel


> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150420/91a90c64/attachment.sig>