Skip to content
Snippets Groups Projects

PluggableTransports

Last edited by Alexander Færøy

org/sponsors/SponsorS/PluggableTransports/Proposal

Task 1: Write the initial evaluation (to be continually revised) of (existing and soon to be deployed transports) following the evaluation criteria as set out in the proposal.

Evaluation criteria for pluggable transport evaluation:

  1. How reviewed / reviewable is it a. Is the software published, and is it entirely free / open source software? Some designs call for non-free (and non-distributable) components like Skype, a copy of Windows in a VM image, etc. b. Is there a published design document, including a threat model? Is there a specification? How testable are its security / unblockability claims? We should also consider how much peer review the design has received already, and whether the project is getting continued attention by its inventors. c. What is its deployment history so far? What kind of users did it have (and how many), and how much publicity? Did it get blocked?

  2. Evaluation of design a. How difficult or expensive will it be to block the design (by protocol, by endpoints, etc)? For example, what services or protocols does it rely on being usable or reachable? Expense could include actual cost or could include collateral damage. Another way to measure might be the fraction of censoring countries where the technique is expected to work. b. What anonymity improvements does the design provide, if any? While many pluggable transports focus only on reachability and leave anonymity properties to Tor, some research designs use the pluggable transport interface to experiment with improved traffic analysis resistance, such as by adding padding to defend better against website fingerprinting attacks. c. What's the bandwidth overhead? Some transports like Obfsproxy don't inflate communication size, while others like Stegotorus wrap their communications in a more innocuous protocol at a cost of sending and receiving more bytes. Designs with higher bandwidth overhead can provide better blocking-resistance, but are also less suited for low-bandwidth environments. d. Scanning-resistance: how does the design fare against active probing attacks, like China's follow-up connections that test for vanilla Tor traffic? ("How the Great Firewall of China is Blocking Tor", Philipp Winter, FOCI 2012). e. Impact on anonymity needs to be expanded to take into consideration things like meek centralizing traffic flows.

  3. Evaluation of implementation: a. Does the implementation use Tor's Pluggable Transport (PT) Application Programming Interface (API) already? Tor has a standard recommended approach so transport modules can be invoked and managed by the Tor process. The PT API also allows Tor to automatically publish capabilities of the transport, collect user and usage statistics from the transport, and so on. b. Is the implementation cross-platform (Windows, OS X, Linux at least)? How about support for mobile platforms? c. How easy is the build process, and how easy is deployment and scaling? For example, what software libraries does it require, how likely are we to get enough bridge-side addresses, etc? d. How is the code from a security and maintainability perspective? Are there unit tests, integration tests, etc? While the underlying Tor channel provides security properties like encryption and authentication, pluggable transports can still introduce new security risks if designed or built improperly. e. How well-instrumented is for the system in terms of collecting usage / performance / etc metrics? And doing so safely?

Transports to be covered:

  • Deployed
    • obfs2
    • obfs3
    • ScrambleSuit
    • FTE
    • meek
    • flashproxy
  • Experimental/To be deployed
    • obfs4 (Tor Browser 4.5-alpha and later)
    • Dust2 (See also Sponsor T)
    • Stegotorus (See also Sponsor F)

Metrics side work required:

  • #8786 (moved) Add extra-info line that tracks the number of consensus downloads of each pluggable transports
  • #10218 (moved) Provide "users-per-transport-per-country" statistics for obfsbridges
  • #14453 (moved) Provide "bridges-per-transport" statistics for obfsbridges

Task 2: Maintain and extend obfsproxy, obfs4proxy, obfsclient and other Pluggable Transport codebases as needed, and assist developers and researchers that wish to use our frameworks to do relevant research.

  • #12535 (moved) goptlib should expose a SOCKS5 server instead of SOCKS4a.
  • #12130 (moved) Figure out deployment strategy for obfs4
  • #13338 (moved) Rewrite tor-fw-helper in Go (or another memory-safe language)
  • Improve the mobile situation wrt Pluggable Transports further.
  • Other things as they come up, because they will...

Task 3: Tor side pluggable transport (and other) related improvements.

  • #2764 (moved) analyze security tradeoffs from using a socks proxy vs a bridge to reach the Tor network
  • #3292 (moved) Let bridge users specify that they don't care if their bridge changes fingerprint
  • #7349 (moved) Obfsbridges should be able to "disable" their ORPort
  • #9957 (moved) Tor should consider stderr output of transport proxies
  • #10671 (moved) Pluggable Transports: Improve method of transferring parameters to client-side transports
  • #10957 (moved) Be more aggressive about enabling Extended ORPort
  • #11138 (moved) Improve code handling SOCKS connection in tor daemon
  • #12456 (moved) Implement prop229 ("Further SOCKS5 extensions") etc.
  • #13074 (moved) “Pluggable transport will not be launched” notice makes it hard to read users' logs
  • #13736 (moved) Kill the DynamicDHGroups feature
  • (To be filed) tor should write bridge lines to a file to make life easier for bridge administrators.

Task 4: Pluggable transport R&D (Catchall)

  • Start thinking about/design a version 2 managed pluggable transport spec to fix the warts in version 1 (IPv6, dualstack boxes, arg passing, disabling network, etc) kpd might want to do this as well).
  • Write a Managed PT externalizer so that people do not need to reinvent the wheel when they write PTs and wish to support more than Tor.
  • Make fog deployable. Might not be a Yawning thing, depends on how much infinity and the student want to do...
  • (Your PT dream project here. "obfs5", "udplol" etc...)

Comments

    Please register or sign in to add a comment.