|
|
|
== 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 [
|
|
|
|
https://www.pluggabletransports.info/spec/pt2draft1] 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 [
|
|
|
|
https://trac.torproject.org/projects/tor/ticket/21816] 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.
|
|
|
|
|
