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,
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
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wed, 08 Oct 2014 16:10:08 +0200 Alexander Dietrich alexander@dietrich.cx wrote:
Will the available obfs4proxy package work on Raspberry Pis, or do we have to compile it from source, like the tor binary?
obfs4proxy has both armel and armhf packages in unstable. The armel packages should work, the armhf packages will not.
NB: I have not tested either, because I do not have the hardware.
Regards,
On 2014-10-08 23:30, Yawning Angel wrote:
obfs4proxy has both armel and armhf packages in unstable. The armel packages should work, the armhf packages will not.
Installing the "armel" package fails because the Pi is "armhf" (or thinks it is).
I tried building the source package, but got some error messages about signature verification both when updating from the "sid" repository and when downloading the source package. Where can I find the missing keys and their fingerprints?
Thanks, Alexander
On 10/09/14, Alexander Dietrich wrote:
On 2014-10-08 23:30, Yawning Angel wrote:
obfs4proxy has both armel and armhf packages in unstable. The armel packages should work, the armhf packages will not.
Installing the "armel" package fails because the Pi is "armhf" (or thinks it is).
I tried building the source package, but got some error messages about signature verification both when updating from the "sid" repository and when downloading the source package. Where can I find the missing keys and their fingerprints?
Thanks, Alexander
Hi Alexander,
FYI, I installed obfs4 today on my Pi using this: https://packages.debian.org/sid/armhf/obfs4proxy/download
Just pick a mirror near you and wget/curl/... the .deb directly. It installs via `dpkg -i` without ado. Whether it's working correctly might be a different story. Log does show this, though: [notice] Registered server transport 'obfs4' at '0.0.0.0:<PORT>'
... which indicates to me that _something_ clicked ;) Also shows up in the "transport" string from onionoo.
Good luck, Oliver
On Thu, 9 Oct 2014 21:01:24 +0200 Oliver Baumann baumanno@cip.ifi.lmu.de wrote:
FYI, I installed obfs4 today on my Pi using this: https://packages.debian.org/sid/armhf/obfs4proxy/download
Just pick a mirror near you and wget/curl/... the .deb directly. It installs via `dpkg -i` without ado. Whether it's working correctly might be a different story. Log does show this, though: [notice] Registered server transport 'obfs4' at '0.0.0.0:<PORT>'
... which indicates to me that _something_ clicked ;) Also shows up in the "transport" string from onionoo.
Since you're running the latest and greatest version of the code, you can look in /var/lib/tor/pt_state/obfs4_bridgeline.txt for your bridgeline[0], and try connecting to it with the TBB alpha snapshots I've been providing.
https://lists.torproject.org/pipermail/tor-dev/2014-September/007535.html
Also, odd. Debian's wiki states that armhf shouldn't work, but maybe I'm misreading the documentation (https://wiki.debian.org/RaspberryPi).
Glad to know that it works, and my continued appreciation to Lunar who made the Debian packages, and thanks for running an obfs4 bridge!
(obfs4proxy can also speak obfs3 if you also want to run one of those, as an alternative to installing obfsproxy. That code is well exercised at this point and we have a bridge running it that has pushed multiple TB worth of obfs3 traffic.)
On 10/09/14, Yawning Angel wrote:
On Thu, 9 Oct 2014 21:01:24 +0200 Oliver Baumann baumanno@cip.ifi.lmu.de wrote:
FYI, I installed obfs4 today on my Pi using this: https://packages.debian.org/sid/armhf/obfs4proxy/download
Just pick a mirror near you and wget/curl/... the .deb directly. It installs via `dpkg -i` without ado. Whether it's working correctly might be a different story. Log does show this, though: [notice] Registered server transport 'obfs4' at '0.0.0.0:<PORT>'
... which indicates to me that _something_ clicked ;) Also shows up in the "transport" string from onionoo.
Since you're running the latest and greatest version of the code, you can look in /var/lib/tor/pt_state/obfs4_bridgeline.txt for your bridgeline[0], and try connecting to it with the TBB alpha snapshots I've been providing.
https://lists.torproject.org/pipermail/tor-dev/2014-September/007535.html
Also, odd. Debian's wiki states that armhf shouldn't work, but maybe I'm misreading the documentation (https://wiki.debian.org/RaspberryPi).
Glad to know that it works, and my continued appreciation to Lunar who made the Debian packages, and thanks for running an obfs4 bridge!
(obfs4proxy can also speak obfs3 if you also want to run one of those, as an alternative to installing obfsproxy. That code is well exercised at this point and we have a bridge running it that has pushed multiple TB worth of obfs3 traffic.)
-- Yawning Angel
[0]: I added that in 0.0.3, you still need to figure out your bridge IP/port and fingerprint, but it beats pulling out the shared secret from the json file.
Hey Yawning,
I fought long and hard with this and found out something. Not being able to connect via obfs4 using the info from bridgeline.txt, I conducted some experiments using info from IRC and obfs4_state.json.
For me to be able to connect to my obfs4-RPi-bridge, I need a bridgeline like this:
bridge obfs4 <IP>:<PORT> $fp $cert $public-key $node-id $iat-mode
... where $public-key and $node-id can be taken from the state.json and PORT is (obviously?) the obfs4-port, not the ORPort (this was not quite so obvious to me).
This bridgeline-format worked for at least one other person having difficulties connecting to their obfs4-bridge, so it might be worth adding a hint somewhere.
Let me know if I can assist,
O.
On Sat, 11 Oct 2014 18:17:34 +0200 Oliver Baumann baumanno@cip.ifi.lmu.de wrote:
I fought long and hard with this and found out something. Not being able to connect via obfs4 using the info from bridgeline.txt, I conducted some experiments using info from IRC and obfs4_state.json.
Oh dear. I am so sorry about that.
For me to be able to connect to my obfs4-RPi-bridge, I need a bridgeline like this:
bridge obfs4 <IP>:<PORT> $fp $cert $public-key $node-id $iat-mode
... where $public-key and $node-id can be taken from the state.json and PORT is (obviously?) the obfs4-port, not the ORPort (this was not quite so obvious to me).
This bridgeline-format worked for at least one other person having difficulties connecting to their obfs4-bridge, so it might be worth adding a hint somewhere.
That's the old bridge line format (changed between 0.0.2 and 0.0.3)[0]. The difference in the formats is the "node-id" and "public-key" parameters were replaced with "cert" (and base64 encoded) to be more compact (so either "cert" or "node-id" + "public-key")[1].
This issue will solve itself eventually, because I will nuke the snapshots once the browser people merge my branch (and master already points to a version that honors the "cert" parameter), but till then:
Bridge obfs4 ip:port fingerprint public-key=<public key> node-id=<node-id> iat-mode=<iat-mode>
Is what people should be using to test things. On new snapshots (or fingers crossed official Tor Browser builds with obfs4 support), what is in the text file will be correct (though the older format is naturally also supported).
Sorry for the confusion,
Does obfs4 support IPv6 addresses? If so, does it work like ORPort in that it is just a matter of adding another line?
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?
Can I use the same ExtORPort for both IPv4 and IPv6 addresses?
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 10/27/2014 06:38 PM, s7r wrote:
-----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
See, the problem is that I *do* have multiple interfaces, each with an IPv4 and IPv6 address. I don't go the "auto" route because I want to avoid having Tor pick the wrong interface/addresses. I want the bridge to run on a given interface and only on that interface.
One more question: how can I test the functionality of obfs4proxy given that TorBrowser v4.0.0 doesn't support this transport?
Thanks for the response.
Hello,
I'll consolidate a few e-mails since replies are spread out.
On Mon, 27 Oct 2014 18:24:49 -0400 Steve Snyder swsnyder@snydernet.net wrote:
Does obfs4 support IPv6 addresses? If so, does it work like ORPort in that it is just a matter of adding another line?
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 obfs4in the config file?
Ooof. "kind of". Pluggable Transport IPv6 support needs a lot of love and is one of the things on my TODO list. The obfs4proxy server code should support IPv6 as well as any other PT, but a lot of the tor and BridgeDB side needs a lot of love before I would consider things well supported.
In particular, the following bugs need to be solved before dual stack bridges are really what I would consider fully functional (regardless of transport, all PTs are affected by these issues).
* https://trac.torproject.org/projects/tor/ticket/7961 * https://trac.torproject.org/projects/tor/ticket/11211 * https://trac.torproject.org/projects/tor/ticket/12138
If you are running a private bridge, or wish to hand out IPv6 addresses to people on your own, then things will "work", till then IPv4 PT bridges are far more useful.
In the obfs4 case, there also is the problem that goptlib exposing a SOCKS4 interface vs SOCKS5 (required for IPv6 client use), so even if the server listens on IPv6 (and it should if told to do so, and also will automatically in certain cases), the client code can't use IPv6 bridges.
* https://trac.torproject.org/projects/tor/ticket/12535
The code is done, but needs more testing, probably in the Tor Browser alpha series.
For now, I would recommend running most PT bridges on IPv4, with the exception of bridges that are manually distributed. Fixing all of this is on my ever growing TODO list, but unfortunately keeps getting pushed back by bigger things being on fire.
Can I use the same ExtORPort for both IPv4 and IPv6 addresses?
The ExtORPort doesn't need to be public because it's only used for communicating between the pluggable transport server code and the tor daemon. So, yes the same one is fine, and I would recommend auto since it only needs to run/work on the loopback interface, unless your configuration is extremely exotic.
One more question: how can I test the functionality of obfs4proxy given that TorBrowser v4.0.0 doesn't support this transport?
You could either "Wait for Tor Browser 4.5-alpha" which I am told will happen "Soon", or run a tor instance and edit the torrc to use your bridge. The same obfs4proxy binary also acts as the client.
The relevant torrc bits for a client would be:
UseBridges 1
# The bridge line from /var/lib/tor/pt_state/obfs4_bridgeline.txt on # the bridge, edited to replace the placeholders. Bridge obfs4 .....
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
Regards,
On Tue, 28 Oct 2014 04:46:37 +0000 Yawning Angel yawning@schwanenlied.me wrote:
You could either "Wait for Tor Browser 4.5-alpha" which I am told will happen "Soon", or run a tor instance and edit the torrc to use your bridge. The same obfs4proxy binary also acts as the client.
Just to quickly follow up on this, Tor Browser 4.5-alpha-1 was released today which includes obfs4proxy fully integrated into the build system and the configuration interface so people should be able to easily test their bridges now.
I'm planning on writing a in-depth blog post talking about obfs4 shortly as well.
Regards,
tor-relays@lists.torproject.org
-
Alexander Dietrich -
Oliver Baumann -
s7r -
Steve Snyder -
Yawning Angel