[tor-dev] Website Fingerprinting Defense via Traffic Splitting

[Mike Perry]

Daniel Forster:
> Hello Guys,
> 
> it would be great if I could get a few opinions regarding my
> upcoming master thesis topic.
> 
> My supervisor is Andriy Panchenko (you may know some of his work
> from Mike Perry's critique on website fingerprinting attacks).
> As a defense, we'd like to experiment with traffic splitting (like
> conflux- split traffic over multiple entry guards, but already
> merging at the middle relay) and padding.
> 
> I know that the no. of entry guards got decreased from three to one.
> May it be worth the research or is the approach heading in a not so
> great direction w.r.t. the Tor Project's "only one entry node"
> decision? Or, actually, what do you think in general..?

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.


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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150107/663ad93f/attachment.sig>