Version 2 (modified by jhelmsen, 9 days ago) (diff)


Pluggable Transport session

Session: #1
Date: 2018/03/12
Time: 14:30:00

Host: John Helmsen
Note taker: Alex

John starts out by introducing the concept of pluggable transport
and transport obfuscation to the meeting participants. We talk shortly
about what people are expecting from the session and try to figure out
who understands what in the world of PT's.

John talks about their obfuscation PT, marionette, that makes the
transport look like traditional HTTP and HTML. We discuss how the system
is impacted by different kinds of overhead of transport size.

John mentions that the documentation of integrating PT's on the Tor
website could be better. John is interested in figuring out how to turn
his obfuscation tool into an actual PT -- currently it is a binary that
exposes a socks proxy port. Alex explains how that is good start and
there is a "small" handshake that has to be done before Tor will start
using the exposed socks port.

OONI have a need for PT's to be available on mobile to test and measure
which types of PT are available and working in different countries.
Adelita mentions that they are probing their PT servers, in different
countries, but they have a problem figuring out if the servers are
actually in the countries where they are claimed to be.

Hans from the Guardian project explains the Android integration problems
and the group discusses the problem with running multiple processes on
different platforms. This is currently a big problem on iOS and we
suspect it might become more and more of a problem in the future on

Operator Foundation is working on the PT spec and implementing PT's in
Apple's swift programming language for easier integration with iOS.

Alex goes over some of the known issues with Tor: PT's are unable to
signal *why* they are failing if they are failing and discusses which
problems that exposes.

We discuss whether it is possible to load a PT as shared library instead
of a binary. We discuss the loading of Go PT's and whether it is
possible with shared libraries.

We talk about Shapeshifter integration in Tor Browser and who should be
contacted for that. Nick suggests talking to Georg Koppen from the
browser team (GeKo).

Alex suggested using dynamic loading of .so files and executing a
specific main function for each individual PT function.

We talk about how far the PT spec is and how far it is from being a
stable release. The PT mailing list is available at:!forum/traffic-obf

Nick mentions that it's good that people are doing PT development in
non-C languages because the memory safety is good to have and makes it
easier to audit the code which is often required before other people are
willing to integrate the code. Nick mentions that there is a price with
using those languages in that it's harder to integrate for different
platforms such a mobile.

Hans mentions that Go binaries are statically linked, which means we
have a big runtime included for every PT that people run. Nick mentions
that the Tor PT architecture can handle multiple transport in a single
process, which will mean that the different PT implementations will have
to be in the same Go binary.

Nick explains the rationale behind the out-of-process design with PT's
and that it's probably a positive thing in the PT ecosystem that PT's
can be written in any language.

Nick mentions that the network team is going to look into making it
possible for PT's to report back to the Tor process with status
information in the nearer future (bidirectional communication between
Tor and the PT).