[tor-dev] Some uncommon use cases for PT library transport selection
David Fifield
david at bamsoftware.com
Mon Jan 13 07:23:42 UTC 2014
On Wed, Dec 18, 2013 at 07:41:42PM -0800, David Fifield wrote:
> I've been thinking about a couple of tricky use cases for pluggable
> transport libraries, and whether we should do anything to try to support
> them.
>
> The first use case is the flashproxy/websocket use case.
> flashproxy-client recognizes the two transport names "flashproxy" and
> "websocket" as synonyms. That is, tor can ask for either one and they
> will work equivalently. But what should happen when tor asks for "*";
> i.e., the activation of all supported transports? We want to start only
> one SOCKS listener, for the preferred name "flashproxy", not a separate
> listener for every synonym. The way that you would indicate you support
> two transport names would be done like this in pyptlib and goptlib
> respectively:
> ptclient.init(["flashproxy", "websocket"])
> ptInfo, err := pt.ClientSetup([]string{"flashproxy", "websocket"})
> but neither of those work for this use case, because if tor asks for
> "*", you get two listeners. Maybe we don't care about this use case,
> because as I understand it, tor will never ask for "*" anyway.
>
> The second use case is the fog* use case. As a server, we may not want
> to declare all the transports we support in advance. Rather, we may
> prefer to look at the names of the transports tor has asked for, and
> decide for each one whether we support it. The idea here is that since
> we can arbitrarily chain a set of transports, we can't just enumerate
> all possible chains and declare those as the transport we support. Both
> pylib and goptlib require you to list all the transports you want to
> support on initialization. We would like for tor to be able to ask for a
> transport name like "obfs3|cbr|obfs3|websocket", and we check to see
> whether we are able to construct such a chain. The current idea is to
> only support a small number of predefined chains in a configuration
> file, so that we can in fact declare them all in advance.
> https://trac.torproject.org/projects/tor/ticket/9744
What I did in goptlib, in both cases, is to have the list of transports
given to ClientSetup and ServerSetup be used only when the "*" list of
transports is requested by tor. In all other cases, you get the full
list of requested transports and have to filter them at the application
level.
David Fifield
More information about the tor-dev
mailing list