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

[Alexander Dietrich]

Will the available obfs4proxy package work on Raspberry Pis, or do we 
have to compile it from source, like the tor binary?

Best regards,
Alexander
---
PGP Key: 0xC55A356B | https://dietrich.cx/pgp

On 2014-09-26 12:32, 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,
> 
> --
> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays