[tor-dev] Towards a new version of the PT spec...

[Yawning Angel]

On Thu, 17 Sep 2015 14:28:24 -0400
Adam Pritchard <a.pritchard at psiphon.ca> wrote:
> At Psiphon we often discuss (and get asked about) using Tor's
> pluggable transports directly. The cost/benefit balance hasn't yet
> been in favour of doing this, but if there's discussion of a big PT
> revamp... maybe Psiphon should indicate how the cost side of the
> balance could come down for us.
>
> We're obviously not a priority for what Tor does with PTs, but there's
> surely no harm in us mentioning our wishlist. So...
> 
> What would be best for us is if PTs were written in Go and implemented
> the net.Conn[1] interface. We have had good results with the
> composability of net.Conn implementations: an obfuscated SSH net.Conn
> on top of a meek net.Conn[2] on top of a upstream proxy net.Conn[3] on
> top of a TCPConn net.Conn[4]. Layering in a PT net.Conn would be sane
> and clean and reasonably easy.
>
> Conversely: Python is difficult-to-impossible due to runtime
> distribution. Separate executables are difficult-to-impossible due to
> Android PIE requirements and distribution size bloat.

The Guardian project people seem to manage to handle distributing
multiple separate executables (tor, meek, obfs4proxy).  I do not know
what they do, maybe they just take the size hit.

> Anyway, if this is of any interest we can discuss it further.

I'm interested in hearing what people want but:

 * I personally am against forcing any particular language on people,
   since the point of PTs is that they are easy for interested parties
   to write.

 * Pluggable Transport implementations sharing address space with the
   Tor binary is basically never going to happen due to security
   concerns (iOS may do weird things, but iOS is not an officially
   supported target).

The revamp is more of a "keeping the current model the same (ie:
fork/exec a helper process with a known external interface), how can we
make said external interface better" than "change the entire Pluggable
Transport concept".

> (Note: Probably Lantern people are reading this too. And probably they
> would benefit from the same things we would, since their architecture
> is similar to ours.)

Now despite all of this, the obfs2/3/4 and ScrambleSuit
implementations I did for obfs4proxy do in fact implement a net.Conn
interface[0] and always have[1].

Regards,

-- 
Yawning Angel

[0]:
https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/transports/base/base.go
[1]:   I reserve the right to implement a hypothetical `obfs5` in
something that is not Go, depending on the availability of required
libraries/primitives, my mood, the phase of the moon, and planetary
alignment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150917/2bb2216a/attachment.sig>