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

[Yawning Angel]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140926/3feca695/attachment.sig>