Some uncommon use cases for PT library transport selection
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 David Fifield * fog is the transport combinator formerly known as Metallica; see https://trac.torproject.org/projects/tor/ticket/9743.
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
participants (1)
-
David Fifield