[anti-censorship-team] TorCloak Pluggable Transport

[David Fifield]

On Fri, Aug 26, 2022 at 06:07:35PM +0100, Francisco Silva via anti-censorship-team wrote:
> We are now coming to a stage on our project in which we are discussing
> solutions to disseminate our bridges. In the attached file we present a small
> draft of our proposed solution. This solution is geared towards leveraging the
> bridge distribution infrastructure already made available by the Tor project
> and make the process of establishing a bridge connection as simple as possible
> for the user.

You can make the bridge report extra arguments to tor, tor will publish
those arguments in the bridge's extra-info descriptor, and then they
will be made part of the bridge line when people get bridges from
BridgeDB. In goptlib, you report such argument using the SmethodArgs
function:
https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#SmethodArgs
For example, obfs4proxy uses SmethodArgs to communicate the "cert"
parameter of bridge lines:
https://gitlab.com/yawning/obfs4/-/blob/77af0cba934d73c4baeb709560bcfc9a9fbc661c/obfs4proxy/obfs4proxy.go#L209

It will probably require some coordination to add TorClock to list of
known transports (e.g. in the dropdown at https://bridges.torproject.org/options/,
in the email responder), if that's how you imagine TorClock bridges
being distributed.

BridgeDB is probably not agile enough to handle something like automatic
rotation of chatroom IDs. It's more suited to long-term stable
identifiers. FYI, BridgeDB is now based on a backend called rdsys:
https://gitlab.torproject.org/tpo/anti-censorship/rdsys
https://forum.torproject.net/t/tor-project-new-bridgedb-version-using-rdsys/2335
I believe one of the ideas behind rdsys was to enable not only long-term
stable bridges like BridgeDB, but also fast-changing ones like the
Snowflake proxy pool. But Snowflake proxies are currently still handled
using a separate and unrelated system. meskio has more knowledge of
rdsys.