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

[Steve Snyder]

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?

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


On 09/26/2014 06:32 AM, Yawning Angel wrote:
> Hello everyone,
>
> As people who have been following Tor Weekly News or other news
> sources, I have been working on a new pluggable transport in the
> obfs-line to better allow censored users to reach the Tor network.
>
> The result, obfs4 is what I would consider ready for general
> deployment[0], and as part of the process there needs to be bridges for
> the users.
>
> To entice people to run obfs4 bridges, I would like to talk briefly
> about obfs4 and obfs4proxy.  I am also planning on doing a blog post
> about obfs4 some time after I regenerate my experimental TBB snapshots.
>
> On obfs4:
>
>    obfs4 is the next up and coming pluggable transport in the obfs[2,3]
>    line, though in terms of design, a better name would be
>    "ScrambleSuit 2".
>
>    The main difference is the switch from UniformDH to
>    ntor-with-Elligator2 for the key exchange process, which means that
>    clients strongly authenticate the identity of the bridge (The key
>    exchange succeeding means that the bridge possesses a Curve25519
>    private key that is known only to the bridge).  Additionally the ntor
>    handshake (even with the Elligator2 transform in the picture) is
>    considerably faster than UniformDH which should increase scalability.
>
> On obfs4proxy:
>
>    obfs4proxy is the current obfs4 reference implementation, written in
>    the Go programming language.  The use of Go was primarily driven by
>    the availability of an Elligator2 implementation at the time, though
>    it also has other practical benefits over writing it as a component
>    of the python obfsproxy code, for example, it is trivial to run
>    bridges listening on ports < 1024 on modern Linux systems.
>
>    obfs4proxy implements support for obfs[2,3,4], as a managed tor
>    pluggable transport (no standalone mode currently).  Note that obfs2
>    support is for backward compatibility purposes only and it is
>    discouraged that new obfs2 bridges are run as the protocol is
>    trivially broken by most adversaries.
>
>    In terms of code stability, we have been running one of the Tor
>    Browser's default obfs3 bridges on obfs4proxy for quite a while with
>    no issues.
>
>    Similar to ScrambleSuit, obfs4 bridges MUST be running tor-0.2.5.x,
>    otherwise the bridge lines that are published will be useless[1],
>    though people that wish to run obfs3 bridges with obfs4proxy
>    naturally can do so with tor-0.2.4.x.
>
>    Source:
>    https://gitweb.torproject.org/pluggable-transports/obfs4.git
>
>    Debian packages (Thanks Lunar!):
>    https://packages.debian.org/sid/obfs4proxy
>
>     Note: I just tagged/pushed obfs4proxy-0.0.2, but the only
>     significant change is that it is easier to get an obfs4 bridge line
>     to give out to people as the bridge operator.  I expect packages to
>     catch up as the wonderful packager has the time.
>
> Questions, comments, and bridges appreciated,
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>