|
|
|
# Sponsor 19
|
|
|
|
Project Title: Addressing Denial of Service Attacks on Free and Open Communication on the Internet
|
|
|
|
|
|
|
|
Project Period: August 15, 2018 - May 31, 2019
|
|
|
|
|
|
|
|
## Project !Goals/Activities
|
|
|
|
Safe communication on the internet requires many components to come together at once: (1) a robust and highly scaled communications infrastructure that protects communications 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.
|
|
|
|
|
|
|
|
With 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.
|
|
|
|
|
|
|
|
Tor Task 1: defend the Tor network itself Tor 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:
|
|
|
|
|
|
|
|
(a) foster diversity and sustainability in relay locations and relay operators,
|
|
|
|
|
|
|
|
(b) react as needed to denial of service attacks on the Tor network itself, and
|
|
|
|
|
|
|
|
(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.
|
|
|
|
|
|
|
|
Tor Task 2: design and deploy better pluggable transports that work in actively censored regimes Currently, 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:
|
|
|
|
|
|
|
|
(a) research and design the missing parts of Snowflake, and build a prototype,
|
|
|
|
|
|
|
|
(b) make Tor Browser releases that integrate this prototype,
|
|
|
|
|
|
|
|
(c) confirm that it does indeed work in denied countries,
|
|
|
|
|
|
|
|
(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
|
|
|
|
|
|
|
|
(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.
|
|
|
|
|
|
|
|
Tor Task 3: build capacity and strengthen the research community Just 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 mostly 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:
|
|
|
|
|
|
|
|
(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.
|
|
|
|
|
|
|
|
Tor Task 4: consider more use cases than just web browsing Smartphone users want privacy and censorship circumvention for more than just web browsing. Millions of people use chat and social media applications, create and share media 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:
|
|
|
|
|
|
|
|
(a) make sure the prototypes and tools from Task two work with Youtube and/or other popular services, and
|
|
|
|
|
|
|
|
(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.
|
|
|
|
|
|
|
|
Tor Task 5: understand Tor’s client performance on limited and/or intermittent connections, and network performance while under attack Several 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 how 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:
|
|
|
|
|
|
|
|
(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), (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 multiple Snowflakes for better performance and better robustness, and (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.
|
|
|
|
|
|
|
|
Tor Task 6: build a network measurement feedback loop so we know what’s working and what should work This feedback loop will be critical to letting us adapt Tor Browser and our other apps in response to changes on the internet. We will:
|
|
|
|
|
|
|
|
(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,
|
|
|
|
|
|
|
|
(b) figure out how to conduct more comprehensive tests too: not just “does webrtc work?” but “does Tor Browser using Snowflake work?”, and
|
|
|
|
|
|
|
|
(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.
|
|
|
|
|
|
|
|
## Project Tracking
|
|
|
|
## Open Tickets
|
|
|
|
[[TicketQuery(status!=closed,sponsor~=Sponsor19,format=table,col=id|summary|component|status|owner)]]
|
|
|
|
|
|
|
|
## Closed Tickets
|
|
|
|
[[TicketQuery(status~=closed,sponsor~=Sponsor19,format=table,col=id|summary|component|status|owner)]] |
|
|
|
\ No newline at end of file |