Changes between Initial Version and Version 1 of org/meetings/2017Montreal/Notes/PluggableTransports

Oct 14, 2017, 9:48:36 PM (3 years ago)

added notes


  • org/meetings/2017Montreal/Notes/PluggableTransports

    v1 v1  
     1PT meeting
     2Saturday 11:00 am
     5        PT 2.0 changes
     6        PT 2.1 Roadmap
     7        Tor patch integration (
     8        Status of current and upcoming transports
     10Brandon gives an overview of purpose and history of pluggable transports.
     12Main changes in PT 2.0: addition of an API, so you can directly link with the transport code.
     13Changed client-side negotation slightly (specifically parameters that were formerly
     14sent over username–password).
     15IANA-reserved SOCKS authentication number exists now.
     17Question: why are pluggable transports recommended as the default way when censored
     18(as opposed to vanilla bridges).
     19Answer: vanilla Tor is easy to discover.
     21Brandon: original idea for PTs was that researchers would write a bunch of transports,
     22and Tor could puck and choose which to incorporate in a modular fashion.
     24Changes in 2.0 are fairly minor.
     26For 2.1, we're in the brainstorming stage, still collecting requirements.
     27Notes on things that people have said that they want (in 2.1):
     28        Protocol (with env vars, stdin/stdout, command-line options) is complicated.
     29        Idea is to take inspiration from Shadowsocks, where the configuration is a config file.
     30        Does a config file offer the same security as env vars (security was the original motivation for env vars)
     32        Go API (not that Tor-related)
     34        Make more parameters optional.
     35        e.g. TOR_PT_MANAGED_TRANSPORT_VER
     37        Swift API, better for iOS and macOS.
     38        (In progress by Operator Foundation)
     40        iOS network extension
     41        Android VPN
     42        a separate app that other apps can use, catches leaks
     43        Question: with whole-device operating modes, are there ways to do circuit isolation?
     44        Nathan: there are some options, such as host isolation in torrc
     46        Packaging: more than "here's the Git repository,"
     47        "here's a package you can install to get started"
     49        Error reporting
     51Enable listening on multiple addresses
     53Limitations that result from the BridgeDB model:
     54no possibility of interactive negotiation for a bridge at connection time,
     55only a static string you got some time in the past.
     58Status of meek?
     59No real changes lately.
     60Meek users at about 10,000, obfs4 at 30,000, vanilla at 5,000.
     63Brandon: unused transports tend to stick around,
     64different products deprecate on their own schedule,
     65transport binaries are written in different languages.
     66Linda Lee looked at the Tor Launcher interface,
     67alternatives to asking users what transport they want to use.
     68Also there was a session a couple days ago about OONI providing Tor Browser
     69with information on current censorship conditions, could help automate choices.
     71There had been a UX thing done on Tor Browser before,
     72developers wanted a lot of bells and whistles and debug information,
     73other users did not.
     75There has been a maintenance problem with transports in Tor Browser,
     76had to drop transports that ceased to build and had few users.
     78Operator Foundation are maintaining their own copies of pluggable transports, as shapeshifter.
     79Rearchitected the code to make it easy to add and remove transports.
     81Back to status of transports.
     82Snowflake current status
     84Choice of Go APi was based on best support at the time,
     85however Go lacks some cross-platform features and isn't good on small embedded devices.
     86You can still use another language.
     88Did you look at using shared objects for pluggable transports (.dll, .so)?
     89Rather than full binaries.
     90That could be an alternate design.
     92There was talk about using TapDance as a pluggable transport.
     93TapDance is in Go, TapDance is an obfuscating protocol.
     94Refraction networking, need cooperation with ISPs.
     96For Shadowsocks, Operator was able to wrap unmodified Shadowsocks code,
     97just translating between Shadowsocks API and PT API.
     99At the last Tor meeting in Amsterdam,
     100we talked about what Tor needs to do to support the PT 2.0 spec
     101Now there's a patch.
     103Brandon asks for help with reviewing and shepherding the patch through.
     105OpenBSD would be willing to help with testing cross-platform compatibility
     106help automate it
     107The requirements for what platforms a patch has to work on were unclear.
     108Chelsea: recently there was a list of Tor's tier-1 platforms published somewhere.
     110Operator tests each of its transports every day in 70-odd countries
     112Question: Since the 2.0 spec is stable, what is the status of UDP ingress?
     113UDP is in the 2.0 spec, is implemented in shapeshifter,
     114transparent proxy mode or STUN-aware protocol.
     115Hasn't really been tested by end users.
     116HardenedBSD would be willing to be a guinea pig.
     117Would help with e.g. UDP daemons like ntpd.
     119How do get people to enable these transports on their bridges?
     120Have a chicken-and-egg problem, Tor doesn't want to merge a transport until there are bridges.