Re: [tor-dev] Some uncommon use cases for PT library transport selection

[David Fifield <david@xxxxxxxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev