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

[Adam Pritchard]

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.

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

(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.)

[1]: https://golang.org/pkg/net/#Conn
[2]: https://github.com/Psiphon-Labs/psiphon-tunnel-core/blob/master/psiphon/meekConn.go
[3]: https://github.com/Psiphon-Labs/psiphon-tunnel-core/tree/master/psiphon/upstreamproxy
[4]: https://golang.org/pkg/net/#TCPConn

Adam Pritchard
Psiphon Inc.


> Date: Mon, 7 Sep 2015 22:45:52 +0000
> From: Yawning Angel <yawning at schwanenlied.me>
> To: tor-dev at lists.torproject.org
> Subject: [tor-dev] Towards a new version of the PT spec...
> Message-ID: <20150907224552.6959bcbc at schwanenlied.me>
> Content-Type: text/plain; charset="us-ascii"
>
> So, we currently have a Pluggable Transport (PT) spec, and it kind-of
> sort-of works (The documentation is a mess that I'm working on
> cleaning up, but it's an orthogonal issue for how well it works).
>
> There are a number of problems with the current PT spec that require
> breaking backward compatibility to fix, so eventually I would like to
> do so.
>
> I'm soliciting input on what people would also like to see in a
> (currently hypothetical) PT spec 2.0 beyond what I already have in mind:
>
>  MUST haves:
>   * Support dual stack Bridges correctly (Multiple server endpoints per
>     transport)
>   * Increase the argument space beyond 510 bytes (Prop. #227).
>   * Mandatory ExtORPort support (currently optional, but metrics are
>     good).
>   * Centralized logging by the calling process (Probably via stderr).
>   * AF_UNIX support where sensible for better sandboxing.
>
>  MIGHT haves:
>   * Rename the env vars to not start with "TOR_PT".  Some people claim
>     that this is a good idea (I think it is stupid and cosmetic).
>   * Ability to force at least clients to stop network activity without
>     tearing the PT down.
>   * Deprecate SOCKS4a, and make SOCKS5 mandatory for clients.
>
>  UNLIKELY:
>   * Specify an interface for where fork()/exec() isn't possible (iOS).
>     I don't think this is makes sense because it is probably too
>     platform/caller specific.
>   * Allow operating both as a client and a server simultaneously.  I
>     don't see a problem with running 2 copies of something for this
>     use case.
>
> I probably missed some things.  If people have strong opinions about
> this, do reply, otherwise I *will* design something that I like, which
> will not include what other people want.
>
> Regards,
>
> --
> Yawning Angel



-- 
Adam Pritchard
Psiphon Inc.