[tor-relays] Call for obfs4 bridges, and a brief discussion of obfs4proxy.

Yawning Angel yawning at schwanenlied.me
Tue Oct 28 04:46:37 UTC 2014


I'll consolidate a few e-mails since replies are spread out.

On Mon, 27 Oct 2014 18:24:49 -0400
Steve Snyder <swsnyder at snydernet.net> wrote:

> Does obfs4 support IPv6 addresses?  If so, does it work like ORPort
> in that it is just a matter of adding another line?
> For example, to add an IPv6 address can I just replace
>      ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__
> with
>      ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__
>      ServerTransportListenAddr obfs4
> [1111:2222:3333:4444::1]:__RNDPORT__
> in the config file?

Ooof.  "kind of".  Pluggable Transport IPv6 support needs a lot of love
and is one of the things on my TODO list.  The obfs4proxy server code
should support IPv6 as well as any other PT, but a lot of the tor and
BridgeDB side needs a lot of love before I would consider things well

In particular, the following bugs need to be solved before dual stack
bridges are really what I would consider fully functional (regardless
of transport, all PTs are affected by these issues).

 * https://trac.torproject.org/projects/tor/ticket/7961
 * https://trac.torproject.org/projects/tor/ticket/11211
 * https://trac.torproject.org/projects/tor/ticket/12138

If you are running a private bridge, or wish to hand out IPv6 addresses
to people on your own, then things will "work", till then IPv4 PT
bridges are far more useful.

In the obfs4 case, there also is the problem that goptlib exposing a
SOCKS4 interface vs SOCKS5 (required for IPv6 client use), so even if
the server listens on IPv6 (and it should if told to do so, and also
will automatically in certain cases), the client code can't use IPv6

 * https://trac.torproject.org/projects/tor/ticket/12535

   The code is done, but needs more testing, probably in the Tor Browser
   alpha series.

For now, I would recommend running most PT bridges on IPv4, with the
exception of bridges that are manually distributed.  Fixing all of this
is on my ever growing TODO list, but unfortunately keeps getting pushed
back by bigger things being on fire.

> Can I use the same ExtORPort for both IPv4 and IPv6 addresses?

The ExtORPort doesn't need to be public because it's only used for
communicating between the pluggable transport server code and the tor
daemon.  So, yes the same one is fine, and I would recommend auto since
it only needs to run/work on the loopback interface, unless your
configuration is extremely exotic.

> One more question: how can I test the functionality of obfs4proxy
> given that TorBrowser v4.0.0 doesn't support this transport?

You could either "Wait for Tor Browser 4.5-alpha" which I am told will
happen "Soon", or run a tor instance and edit the torrc to use your
bridge.  The same obfs4proxy binary also acts as the client.

The relevant torrc bits for a client would be:

 UseBridges 1

 # The bridge line from /var/lib/tor/pt_state/obfs4_bridgeline.txt on
 # the bridge, edited to replace the placeholders.
 Bridge obfs4 .....

 ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy


Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20141028/793fde89/attachment-0001.sig>

More information about the tor-relays mailing list