GoSC - Website Fingerprinting project
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm a PhD student at COSIC (COmputer Security and Industrial Cryptography) in KU Leuven, Belgium. My research topic is related to network traffic analysis and I'm now focused in the more specific problem of website fingerprinting (http://homes.esat.kuleuven.be/~mjuarezm/). I think website fingerprinting is one of the most threatening attacks to Tor because it can be deployed with moderate resources and the information that can be extracted as a result is highly sensitive (e.g., browsing history). It basically defeats one of the main privacy guarantees offered by Tor which is unlinkability between sender and recipient or, in this particular case, between the user and the web server. However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects. That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack. Regarding countermeasures, since Tor is oriented to low-latency applications like web browsing, delaying strategies are unacceptable and, therefore, they must necessarily be based on link-padding. Link-padding normally incurs in high bandwidth overheads, however the increasing broadband bandwidth capacity available makes it a relevant feasible defence. Some capabilities for link-padding have been already specified for Tor by Steven Murdoch (https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.tx..., Section 7.2). This functionality is very useful for such a countermeasure but more sophisticated protocols are required for countermeasures that try to adjust the bandwidth overhead. There are several proposed countermeasures based on link-padding that strive for such a trade-off that might be interesting to implement: - Congestion-Sensitive BuFLO (http://arxiv.org/abs/1401.6022) - Adaptive Padding (http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf) Both countermeasures have some building blocks in common (e.g., a control logic to adapt padding under some specific conditions and reduce the overhead). The core of the project would be to implement them in the most general way as possible so they can be useful for other link-padding applications. For example, to implement the basis for a statistical model in the onion proxy and the entry guard that generates the appropriate cover traffic in both directions, where ?appropriate? would be abstracted as it would be defined by each specific countermeasure. I would like to have some feedback from the Tor developers about this project (advices, comments..). I plan to specify it in more detail in the application and to start coding some module that could be shown. But I would like to know if the underlying idea is something that could be of interest for the community. Also, as a PhD student I'm also committed with my research group during the summer so I would like to know if I could work as a part-time student. Best, - -- marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHe+dAAoJEGfJ5xfgazlxYewH/jHv3843o0lQHpHksur86dih u1MtFOpo3RvzdOLNAjdMpnV14Giy8cg0mIcYdCgwCy8jyUgBS5ipX49582Tmf6FT sPYYWOSIBEJVG3DYsD2PwU+XJAiyR9GqdiMiP9MeCJHWP33TBL5hY1TExBejiH+J XsAWo8D2MkzycKITF1leuX4n2eCqncDIy+owU4faYIRj5wPtqwztWDX4ErfdFhws sb/wLF8Wb0tKio/ybkuy5UZeJi0UBF9hAh5UJfZRSllfMFN9g29pJPmTsenMTBS0 XxEEG8gNjHgxpV4rkcTMQBeNp+CAEBsZ7qjxo6IXvLIe0P6zutyQysu9hJCvvY4= =AZG8 -----END PGP SIGNATURE-----
Marc Juarez:
I think website fingerprinting is one of the most threatening attacks to Tor because it can be deployed with moderate resources and the information that can be extracted as a result is highly sensitive (e.g., browsing history). It basically defeats one of the main privacy guarantees offered by Tor which is unlinkability between sender and recipient or, in this particular case, between the user and the web server. However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects. That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack.
Have you read Mike Perry's long blog post on the topic? https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-att... It outlines future research work in evaluating the efficiency of fingerprinting attacks, and also mention a couple of promising defenses. -- Lunar <lunar@torproject.org>
On Mon, Mar 10, 2014 at 06:00:13PM +0100, Marc Juarez wrote:
I'm a PhD student at COSIC (COmputer Security and Industrial Cryptography) in KU Leuven, Belgium. My research topic is related to network traffic analysis and I'm now focused in the more specific problem of website fingerprinting (http://homes.esat.kuleuven.be/~mjuarezm/).
Welcome!
However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects
We moved the 'research' ideas from the volunteer page to https://research.torproject.org/ideas.html a while ago. (Also, most of the research ideas don't have to do primarily with coding, so they're not as suited for GSoC.)
That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack. [snip] I would like to have some feedback from the Tor developers about this project (advices, comments..). I plan to specify it in more detail in the application and to start coding some module that could be shown. But I would like to know if the underlying idea is something that could be of interest for the community.
It's definitely something that we need at some point. But I think your first challenge will be finding a mentor with both the time and interest to help you make it work. It seems like some of the approaches would best be done inside Tor (as modifications to the Tor program), and some of them would best be done in a separate pluggable transport? Or should they all be done in a PT? Can the bandwidth shaping in Scramblesuit (obfsproxy) be used as a building block here? It sounds like the implementation might be the easy part, compared to the design part. And since GSoC is mostly about implementation, and we would want to be confident you won't spend all summer distracted by design, it would be best if your proposal includes a lot of the design.
Also, as a PhD student I'm also committed with my research group during the summer so I would like to know if I could work as a part-time student.
That could be a problem -- gsoc wants to be a full time job, and we've had bad experiences in the past with people who try to do two jobs at once. Part of the goal of gsoc is let you focus so you can get integrated into the Tor community (rather than supplementing your income to stay in your research group). --Roger
On Wed, 12 Mar 2014 16:25:20 -0400 Roger Dingledine <arma@mit.edu> wrote:
It seems like some of the approaches would best be done inside Tor (as modifications to the Tor program), and some of them would best be done in a separate pluggable transport? Or should they all be done in a PT? Can the bandwidth shaping in Scramblesuit (obfsproxy) be used as a building block here?
This depends on what all wants to be tested. Basing it off ScrambleSuit would pull in a lot of code that's probably unnecessary. If it were me doing this, I would write a simple transport that has hooks for adjusting the packet size/inter packet timing. Assuming a basic familiarity with python (bonus points for Twisted), this would be about an afternoon worth of code (if that), and from there real development on different padding strategies could be researched. Regards, -- Yawning Angel
Roger Dingledine <arma@mit.edu> writes:
On Mon, Mar 10, 2014 at 06:00:13PM +0100, Marc Juarez wrote:
I'm a PhD student at COSIC (COmputer Security and Industrial Cryptography) in KU Leuven, Belgium. My research topic is related to network traffic analysis and I'm now focused in the more specific problem of website fingerprinting (http://homes.esat.kuleuven.be/~mjuarezm/).
Welcome!
However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects
We moved the 'research' ideas from the volunteer page to https://research.torproject.org/ideas.html a while ago.
(Also, most of the research ideas don't have to do primarily with coding, so they're not as suited for GSoC.)
That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack. [snip] I would like to have some feedback from the Tor developers about this project (advices, comments..). I plan to specify it in more detail in the application and to start coding some module that could be shown. But I would like to know if the underlying idea is something that could be of interest for the community.
It's definitely something that we need at some point. But I think your first challenge will be finding a mentor with both the time and interest to help you make it work.
It seems like some of the approaches would best be done inside Tor (as modifications to the Tor program), and some of them would best be done in a separate pluggable transport? Or should they all be done in a PT? Can the bandwidth shaping in Scramblesuit (obfsproxy) be used as a building block here?
Might be a mere technicality, but it's currently the case that only bridges and bridge clients can use PTs. If we ever wanted to deploy these anti-traffic-analysis PTs to the whole network, we would have to add PT support to all clients (HSes might also benefit from this) and to all relays.
participants (5)
-
George Kadianakis -
Lunar -
Marc Juarez -
Roger Dingledine -
Yawning Angel