On Thu, 17 Sep 2015 14:28:24 -0400 Adam Pritchard <a.pritchard@xxxxxxxxxx> 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.
Attachment:
pgpxiFeTj3QdG.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev