[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Towards a new version of the PT spec...
I mostly just want to second everything Adam P has already said and to
emphasize some details. For us, PTs implemented in Go is a huge win
and is enough that we'll likely integrate obfs4 directly into Lantern
(https://www.getlantern.org). I happen to have just been looking at
the net.Conn interface implementation in particular, which I agree is
very handy.
The runtime size issue is really a significant one. Particularly in
Iran, a download size over maybe 10MB is just often a deal breaker in
practice.
More broadly it would be amazing on our end if PTs were a little more
decoupled (or pluggable!) from not just Tor but also SOCKS, HTTP, etc,
and when I say that I mean at all of the following layers:
1) Code
2) Configuration
3) Documentation
For example, just a simple example of wrapping an existing net.Conn
with obfs4 without getting into the details of the Tor config and
environment variables or even jumping through SOCKs hoops would likely
have seen obfs4 integrated into Lantern *today* and deployed at scale
potentially next week. In that example, I think making PTs more easily
usable even outside of the whole PT framework would also be a huge
improvement - i.e. for us we'd ideally not take the performance hit of
jumping through an extra proxy even though that approach makes a lot
of sense in the larger PT context. All of that is doable now of
course, but takes a little digging.
Now, to be clear, the beauty of PTs, and what makes this discussion
even possible, is how decoupled they already are. I suggest that
taking that decoupling to the next level could have really nice
cascading effects for PTs. For example, I think it would make both us
and Psiphon quite likely to use them (TBH we'll probably use them
again anyway, as I said), but that also means two strong decent-sized
full time teams contributing to debugging, patching, documentation,
etc. We also both run at significant scale in censored regions where
PTs are obviously particularly useful, so we'd be likely to contribute
to things like benchmarking and performance improvements if not
additional PTs themselves.
Anyway, thanks for listening. I think PTs are a truly awesome example
of a cool "architecture of participation", and we'd love to help make
them even more participatory and powerful!
-Adam Fisk
Brave New Software Project, Inc.
On Thu, Sep 17, 2015 at 11:28 AM, 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.
>
> 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@xxxxxxxxxxxxxxx>
>> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
>> Subject: [tor-dev] Towards a new version of the PT spec...
>> Message-ID: <20150907224552.6959bcbc@xxxxxxxxxxxxxxx>
>> 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.
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
--
President
Brave New Software Project, Inc.
https://www.getlantern.org
pgp A998 2B6E EF1C 373E 723F A813 045D A255 901A FD89
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev