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

[s7r <s7r@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 10/28/2014 12:24 AM, Steve Snyder wrote:
> Does obfs4 support IPv6 addresses?  If so, does it work like ORPort
> in that it is just a matter of adding another line?
> 
> 
Yes.

> 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?
> 
Yes, that sounds right. If you don't have multiple interfaces or don't
care if you open the ports on all interfaces, here is how I do it:
I use ServerTransportListenAddr obfs4 [::]:_RNDPORT_ -> it opens the
obfuscated ports on both v4 and v6 (dual stack).

If you do so, do it to ORPort also, so it will be a fully dual stack
bridge, like:
ORPort 111.222.333.444:_PORT_
ORPort [111.222.333.444::1]:_PORT_

> Can I use the same ExtORPort for both IPv4 and IPv6 addresses?
> 
Just use

ExtORPort auto

and it will prefer v6 (if enabled on your OS) and fall back to v4 if
v6 fails (it will take the configuration from your OS network stack).
ExtORPort auto is your best option.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUTsl5AAoJEIN/pSyBJlsRBrsIAMse7fSQfSrRmcSHe9IPiWSi
UqWM95t+AeE8bqFwSpFhuwavvZ0Jt1Ll7WKclJKlq66z9qWs1hwVsB4mqSkIt9dm
1pHNlFNh5dakk1o413ZHRpTNQskWG9YGCv20vNTwlbHZlZ1InXr7e6Qy2/31o8Hc
P/EEGNBOjTMe6Y/XOR5LVndjZgb0vYkbL8Kk8ETKb8kQAnb3TOxE9A3VBQ4FVnMJ
uLJyz9Fx68G1HG5RtAp9k7nsFPJ1oyiq/Hr2OOO8Z5sPjiPdhxFLyo4V6UrZ7YMm
ysnSK2iEOqc3m7+MnfMK0OBVqSyCYgJE/JR1CjPuPCtzcLuVAxyVDVDGuHKDv/g=
=Pans
-----END PGP SIGNATURE-----
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays