[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>

[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

Post by 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.
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.
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.
https://gitweb.torproject.org/pluggable-transports/obfs4.git
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

[Yawning Angel]

On Wed, 08 Oct 2014 16:10:08 +0200

Post by Alexander Dietrich
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,

[Alexander Dietrich]

Post by Yawning Angel
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

[Oliver Baumann]

Post by Yawning Angel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20141009/244a4e5c/attachment.sig>

[Yawning Angel]

On Thu, 9 Oct 2014 21:01:24 +0200

Post by Oliver Baumann
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
[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.
-------------- 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/20141009/9106ab80/attachment.sig>

[Oliver Baumann]

Post by Yawning Angel
On Thu, 9 Oct 2014 21:01:24 +0200

Post by Oliver Baumann
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
[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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20141011/057a071f/attachment.sig>

[Yawning Angel]

On Sat, 11 Oct 2014 18:17:34 +0200

Post by Oliver Baumann
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.

Post by Oliver Baumann
For me to be able to connect to my obfs4-RPi-bridge, I need a
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,
--
Yawning Angel

[0]:https://gitweb.torproject.org/pluggable-transports/obfs4.git/commit/6cd81ec42f203585c59e610dc16728cb0a5d1455

[1]: "cert" is b64(node-id | public-key), with the trailing "="s
removed. A trivial $languageOfChoice script can convert between the
two, though as you noted, pulling the parameters out of the JSON file
in the meantime isn't too difficult.
-------------- 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/20141011/9326d812/attachment.sig>

[Steve Snyder]

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?

Post by 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.
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.
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.
https://gitweb.torproject.org/pluggable-transports/obfs4.git
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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[s7r]

Post by Steve Snyder
Does obfs4 support IPv6 addresses? If so, does it work like ORPort
in that it is just a matter of adding another line?

Yes.

Post by Steve Snyder
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_

Post by Steve Snyder
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.

Post by Steve Snyder

Post by 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.
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.
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.
https://gitweb.torproject.org/pluggable-transports/obfs4.git
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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

_______________________________________________ tor-relays mailing
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[Steve Snyder]

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

Post by Steve Snyder
Does obfs4 support IPv6 addresses? If so, does it work like ORPort
in that it is just a matter of adding another line?

Yes.

Post by Steve Snyder
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
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
ORPort 111.222.333.444:_PORT_
ORPort [111.222.333.444::1]:_PORT_

Post by Steve Snyder
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.

[Yawning Angel]

Hello,

I'll consolidate a few e-mails since replies are spread out.

On Mon, 27 Oct 2014 18:24:49 -0400

Post by Steve Snyder
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?

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.

Post by Steve Snyder
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.

Post by Steve Snyder
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,

[Yawning Angel]

On Tue, 28 Oct 2014 04:46:37 +0000

Post by Yawning Angel
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,