Changes between Version 2 and Version 3 of org/sponsors/Sponsor19


Ignore:
Timestamp:
Dec 4, 2018, 10:25:42 PM (6 months ago)
Author:
bekeela
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • org/sponsors/Sponsor19

    v2 v3  
    11= Sponsor 19 =
    22
    3 Censorship, denial-of-service, research. [We should add more details here.]
     3Censorship, denial-of-service, research.
     4
     5Title: Addressing Denial of Service Attacks on Free and Open Communication on the Internet
     6
     7Safe communication on the internet requires many components to come together at once: (1) a robust and highly scaled communications infrastructure that protects
     8communications metadata (i.e. Tor); (2) mechanisms to get around blocking or censorship of connections between users and this privacy network; (3) suitable packages designed for the computing environments of real users, with an emphasis on usability and user experience; and (4) awareness of the changing landscape of threats, and adaptive user education about these threats.
     9
     10With these components in mind, we will focus on six areas of work. Note that each of these areas is itself an open-ended research field, so while we want to make substantial progress on each of them, there will always be more follow-up work to do on each of them.
    411
    512== Timeline ==
    613
    714August 2018 through May 2019.
     15
     16== Tasks ==
     17Tor Task 1: defend the Tor network itself
     18Tor is a free-software anonymizing overlay network that helps people around the world use the internet in safety. Tor’s 8000 volunteer relays carry over 100Gbit/s of traffic for several million users each day. This deployed network and diverse user base provides a great foundation, but we must make it stronger. We will:
     19
     20
     21(a) foster diversity and sustainability in relay locations and relay operators,
     22
     23
     24(b) react as needed to denial of service attacks on the Tor network itself, and
     25
     26
     27(c) proactively identify and resolve DoS vulnerabilities, making use of existing research collabo-rations to achieve a stronger network and improve robustness to unknown DoS vectors.
     28
     29
     30Tor Task 2: design and deploy better pluggable transports that work in actively censored regimes
     31Currently, domain fronting systems like meek work in most or all denied countries, but domain fronting scales poorly both in terms of bandwidth and monetary cost. The most promising of the next generation of PTs is Snowflake, which builds on Flash Proxy to use in-browser webrtc to make “Google Hangout” style connections to volunteer web browsers, who then bridge the connections on to the Tor network. We will:
     32
     33
     34(a) research and design the missing parts of Snowflake, and build a prototype,
     35
     36
     37(b) make Tor Browser releases that integrate this prototype,
     38
     39
     40(c) confirm that it does indeed work in denied countries,
     41
     42
     43(d) get some pluggable transports, including Snowflake, working on Android too, since an increas-ing percentage of the world is moving from desktop to mobile, and
     44
     45
     46(e) start research and development on something to follow Snowflake so we’re prepared if attackers become willing to block or degrade the webrtc protocol.
     47
     48
     49Tor Task 3: build capacity and strengthen the research community
     50Just about every major security conference these days has a paper analyzing, attacking, or improv-ing Tor. While ten years ago the field of anonymous communications was
     51mostly theoretical, with researchers speculating that a given design should or shouldn’t work, Tor now provides an actual deployed testbed. Tor has become the gold standard for anonymous communications research, which in turn triggered an explosion of academic pluggable transport designs. We will:
     52
     53(a) collaborate with members of the PETS research community to continue operation of the Tor Research Safety Board (a group of researchers who study Tor, and who want to minimize privacy risks while fostering a better understanding of the Tor network and its users), with the output being a growing set of real-world case studies on how to safely and ethically conduct experiments on the live Tor network and users.
     54
     55Tor Task 4: consider more use cases than just web browsing
     56Smartphone users want privacy and censorship circumvention for more than just web browsing. Millions of people use chat and social media applications, create and share
     57media files like images and video, and more. In fact, if Tor’s performance penalties are most visible for latency-sensitive applications like web browsing, we would be wise to explore secure messaging and other asyn-chronous applications. We will:
     58
     59
     60(a) make sure the prototypes and tools from Task two work with Youtube and/or other popular services, and
     61
     62
     63(b) do a needs assessment for what other applications are popular among users behind censorship, and how well we can serve them, considering both safety and usability. The first challenge is to understand what would actually be useful to build. Options to consider include designing a video sharing service that integrates characteristics of SecureDrop or Globaleaks, or adding an “upload resume” or “parallel upload” helper to Tor Browser so users can upload chunks at a time and not have to start over when the network fails.
     64
     65Tor Task 5: understand Tor’s client performance on limited and/or intermittent connections, and network performance while under attack
     66Several factors contribute to making Tor connections less efficient than a direct connection to the final destination, and while a big part of that difference can be explained by
     67how much capacity is available at the Tor relays (see Task one), some of these performance factors are particularly acute on bad network connections. At the same time, we need to better understand how load on the network itself, including adversarially-induced or targeted load, can impact all parts of the system. We will:
     68
     69
     70(a) consider and analyze the end-to-end performance and congestion of Tor clients behind bad network connections (high-latency, low-bandwidth, some packet loss, etc),
     71(b) design ways to get around these limitations, for example with the “resume” feature mentioned above, or by having clients stripe their connections and/or circuits over
     72multiple Snowflakes for better performance and better robustness, and
     73(c) study the behavior of Tor clients and Tor relays under various denial of service attacks, and design countermeasures to tolerate the attacks and/or gracefully degrade service.
     74
     75Tor Task 6: build a network measurement feedback loop so we know what’s working and what should work
     76This feedback loop will be critical to letting us adapt Tor Browser and our other apps in response to changes on the internet. We will:
     77
     78
     79(a) ramp up our OONI-style censorship measurement tests in denied areas, so we can confirm that various protocols like webrtc do work right now, and so we can get rapid and robust notifications when that changes,
     80
     81
     82(b) figure out how to conduct more comprehensive tests too: not just “does webrtc work?” but “does Tor Browser using Snowflake work?”, and
     83
     84
     85(c) maintain and grow our Tor Metrics data sets, which provide historical and ongoing Tor network data and performance statistics for the broader research community.
    886
    987== Open Tickets ==