Pluggable Transports

We started with an overview Tor's existing PT system:

tor launches obfs4proxy, which is written in Go, as a separate process. tor communicates with obfs4proxy via an IPC mechanism defined in the PT 1.0 specification. This IPC mechanism consists of three methods of communication. tor sends information to obfs4proxy using environment variables. obfs4proxy sends information to tor using stdout. tor also communicates per-connection parameters to obfs4proxy using a variant of the SOCKS protocol. Username and password authentication is negotiated using the SOCKS authentication method negotiation. The per-connection parameters for the transport are then encoded so that they are split over the username and password fields. obfs4proxy provides multiple transports: obfs2, obfs3, obfs4, scramblesuit, and meek. obfs4proxy is distributed with TorBrowser, Orbot, and OnionBrowser. obfs4proxy internally uses goptlib to implement the IPC protocol. Snowflake is another PT written in Go, but it is not part of obfs4proxy. It is a separate executable, which also uses goptlib to implement the IPC protocol. Snowflake is bundled with newer version of TorBrowser.

We then discussed new developments in the PT ecosystem: PT 2.0, Shapeshifter, and Transport Canaries.

The PT 2.0 specification [] was created by a committee of censorship circumvention tool developers: Tor, Lantern, Psiphon, and uProxy. It specifies a version of Pluggable Transports that meets the needs of multiple circumvention tools. Most of the changes are not important to Tor. For instance, a Go API for transports is specified. This standardizes how new transports can be added to obfs4proxy. However, since tor uses the IPC mechanism it does not see these internal changes. There is one major change that has implications for tor, which is that the PT 2.0 IPC protocol uses a different type of SOCKS authentication mechanism, which allows for larger parameters.

Shapeshifter is an implementation of the PT 2.0 specification. It is forked from obfs4proxy. It has two components: shapeshifter-transports and shapeshifter-dispatcher. shapeshifter-transports provide PT 2.0 Go API-compatible versions of obfs4 and meek transports. Shapeshifter-dispatcher wraps these transports in the PT 2.0 IPC mechanism so that they can be launched as a separate process. Shapeshifter also provides a new transport, shadow, which uses the Shadowsocks protocol for obfuscation.

Transport Canaries is a project to test reachability of PTs on networks where they might be blocked. The goal of this project is to provide packet-level network traffic capture data of PT blocking so that better PTs can be developed. Additionally, the Transport Canaries will report high-level PT reachability statistics to OONI.

We then talked about next steps for PTs and Tor. In order for tor to be PT 2.0 compliant, the code in tor that talks to obfs4proxy must be upgraded so that it can use the PT 2.0 IPC mechanism. It is a small change, and can be done in a way that is backwards compatible. A trac ticket was opened [] and a description of what would be necessary in a patch was added.

In addition to patching tor, a PT 2.0-compliant implementation of the transports is needed. There are two basic options. The first option is that obfs4proxy can be replaced with Shapeshifter. The second option is that PT 2.0-compliance changes can be backported from Shapeshifter to obfs4proxy. The advantage to using Shapeshifter is that it is being developed by a group of circumvention tool developers. It has independent funding, and will continued to be developed while Tor's resources are dedicated to other projects. This includes the development of new transports, such as the Shadowsocks transport. The advantage to backporting changes to obfs4proxy is that Shapeshifter has some additional features needed by other circumvention tools, but not needed by Tor. For instance, Shapeshifter supports proxying of UDP application traffic and tor does not. As a possible compromise, Shapeshifter could be modified to use conditional compilation so that features not used by Tor could be turned off so that those code paths are not included when the executable is built.

Open issues to be discussed in the future are who the point of contact should be within Tor to discuss PT issues, how the decision making process will be made between adopting Shapeshifter vs. porting changes to obfs4proxy, and who will write the PT 2.0 IPC patch to tor that is outlined in the Trac ticket.

We also discussed the continuing need for the development of new PTs, particularly as obfs4 is currently being blocked on some networks.

Last modified 4 weeks ago Last modified on Apr 3, 2017, 3:58:13 PM