wiki:org/meetings/2017Montreal/Notes/PluggableTransports

PT meeting Saturday 11:00 am

Agenda:

PT 2.0 changes PT 2.1 Roadmap Tor patch integration (https://bugs.torproject.org/21816) Status of current and upcoming transports

Brandon gives an overview of purpose and history of pluggable transports.

Main changes in PT 2.0: addition of an API, so you can directly link with the transport code. Changed client-side negotation slightly (specifically parameters that were formerly sent over username–password). IANA-reserved SOCKS authentication number exists now.

Question: why are pluggable transports recommended as the default way when censored (as opposed to vanilla bridges). Answer: vanilla Tor is easy to discover.

Brandon: original idea for PTs was that researchers would write a bunch of transports, and Tor could puck and choose which to incorporate in a modular fashion.

Changes in 2.0 are fairly minor.

For 2.1, we're in the brainstorming stage, still collecting requirements. Notes on things that people have said that they want (in 2.1):

Protocol (with env vars, stdin/stdout, command-line options) is complicated. Idea is to take inspiration from Shadowsocks, where the configuration is a config file. Does a config file offer the same security as env vars (security was the original motivation for env vars)

Go API (not that Tor-related)

Make more parameters optional. e.g. TOR_PT_MANAGED_TRANSPORT_VER

Swift API, better for iOS and macOS. (In progress by Operator Foundation)

iOS network extension Android VPN a separate app that other apps can use, catches leaks Question: with whole-device operating modes, are there ways to do circuit isolation? Nathan: there are some options, such as host isolation in torrc

Packaging: more than "here's the Git repository," "here's a package you can install to get started"

Error reporting

Enable listening on multiple addresses

Limitations that result from the BridgeDB model: no possibility of interactive negotiation for a bridge at connection time, only a static string you got some time in the past.

Status of meek? No real changes lately. Meek users at about 10,000, obfs4 at 30,000, vanilla at 5,000. https://metrics.torproject.org/userstats-bridge-transport.html?start=2017-07-16&end=2017-10-14&transport=obfs3&transport=obfs4&transport=fte&transport=meek&transport=%3COR%3E

Brandon: unused transports tend to stick around, different products deprecate on their own schedule, transport binaries are written in different languages. Linda Lee looked at the Tor Launcher interface, alternatives to asking users what transport they want to use. Also there was a session a couple days ago about OONI providing Tor Browser with information on current censorship conditions, could help automate choices.

There had been a UX thing done on Tor Browser before, developers wanted a lot of bells and whistles and debug information, other users did not.

There has been a maintenance problem with transports in Tor Browser, had to drop transports that ceased to build and had few users.

Operator Foundation are maintaining their own copies of pluggable transports, as shapeshifter. Rearchitected the code to make it easy to add and remove transports.

Back to status of transports. Snowflake current status

Choice of Go APi was based on best support at the time, however Go lacks some cross-platform features and isn't good on small embedded devices. You can still use another language.

Did you look at using shared objects for pluggable transports (.dll, .so)? Rather than full binaries. That could be an alternate design.

There was talk about using TapDance as a pluggable transport. TapDance is in Go, TapDance is an obfuscating protocol. Refraction networking, need cooperation with ISPs.

For Shadowsocks, Operator was able to wrap unmodified Shadowsocks code, just translating between Shadowsocks API and PT API.

At the last Tor meeting in Amsterdam, we talked about what Tor needs to do to support the PT 2.0 spec Now there's a patch. https://trac.torproject.org/projects/tor/ticket/21816 Brandon asks for help with reviewing and shepherding the patch through.

OpenBSD would be willing to help with testing cross-platform compatibility help automate it The requirements for what platforms a patch has to work on were unclear. Chelsea: recently there was a list of Tor's tier-1 platforms published somewhere.

Operator tests each of its transports every day in 70-odd countries

Question: Since the 2.0 spec is stable, what is the status of UDP ingress? UDP is in the 2.0 spec, is implemented in shapeshifter, transparent proxy mode or STUN-aware protocol. Hasn't really been tested by end users. HardenedBSD would be willing to be a guinea pig. Would help with e.g. UDP daemons like ntpd.

How do get people to enable these transports on their bridges? Have a chicken-and-egg problem, Tor doesn't want to merge a transport until there are bridges.

Last modified 11 months ago Last modified on Oct 14, 2017, 9:48:36 PM