[tor-dev] Website Fingerprinting Defense via Traffic Splitting

Daniel Forster daniel.forster at rwth-aachen.de
Mon Apr 20 08:35:06 UTC 2015

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.


> _______________________________________________
> 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>

More information about the tor-dev mailing list