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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays