[tor-relays] Call for obfs4 bridges, and a brief discussion of obfs4proxy.
alexander at dietrich.cx
Wed Oct 8 14:10:08 UTC 2014
Will the available obfs4proxy package work on Raspberry Pis, or do we
have to compile it from source, like the tor binary?
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, 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,
> though people that wish to run obfs3 bridges with obfs4proxy
> naturally can do so with tor-0.2.4.x.
> Debian packages (Thanks Lunar!):
> 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
> : https://trac.torproject.org/projects/tor/ticket/12130
> : https://trac.torproject.org/projects/tor/ticket/13202
> tor-relays mailing list
> tor-relays at lists.torproject.org
More information about the tor-relays