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,
--
Yawning Angel
[0]: https://trac.torproject.org/projects/tor/ticket/12130
[1]: https://trac.torproject.org/projects/tor/ticket/13202
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays