Opened 6 years ago

Closed 5 years ago

#12130 closed task (fixed)

Figure out deployment strategy for obfs4

Reported by: asn Owned by: asn
Priority: Medium Milestone:
Component: Circumvention/Pluggable transport Version:
Severity: Keywords: bridgedb-pts, bridgedb-0.2.4, isis2014Q3Q4, isis2015Q1Q2
Cc: phw, yawning, isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


While we were busy doing other things, Yawning created his own PT which supercedes scramblesuit. obfs4 (this is a temporary name), aims to have all the features of scramblesuit and a bit more (for example, it has better performance because of Elligator instead of UniformDH).

The code can be found at and apparently it already has feature parity with scramblesuit.

We should decide whether we should deploy obfs4 and when.

Some possible avenues:

  • Deploy both scramblesuit and obfs4. This is a bit pointless since obfs4 does not have any real threat model differences over scramblesuit. And deploying another transport means that we have to ask bridge operators to upgrade, and users to learn another transport name (crying wolf paradigm applies here too). Also, maintaining two similar codebases is a bit stupid.
  • Deploy obfs4 instead of scramblesuit. This makes more sense since obfs4 is supposedly strictly better than scramblesuit. However:
    1. scramblesuit is already a bit deployed. We have a few bridges already running it, and it was also recently added in the TBB
    2. obfs4 is untested and will probably need some time to pass quality control and review.
    3. obfs4 is a go application, so it needs an extra patch to the TBB build process.
  • Continue scramblesuit deployment, and hold on to obfs4. Maybe we can use obfs4 as an emergency transport in the future. Unfortunately, this is suboptimal. since it means that we will have to write TBB build patches to deploy the emergency transport. It would make more sense to hold on scramblesuit as the emergency transport (since it's already in obfsproxy).

Child Tickets

#12453closederinn, nickm, Sebastian, weaselPlease create obfs4 repositories.Internal Services/Service - git
#12605closedyawningobfs4 bridges should autogenerate keys when invoked with no arguments.Circumvention/Pluggable transport
#12606closedyawningRefactor obfs4proxy (and the support protocol code)Circumvention/Pluggable transport
#12903closedyawningIntegrate obfs4proxy into the TBB bundle.Circumvention/Pluggable transport
#12910closedlunarCreate packages for obfs4proxy for bridge administrators.Circumvention/Pluggable transport
#12932closedisisTransport Key-Value pairs should be space separatedCircumvention/BridgeDB

Attachments (1)

obfs4-bundle.diff (17.0 KB) - added by yawning 6 years ago.
Round 2, with windows fixed.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 6 years ago by phw

Cc: phw added

comment:2 Changed 6 years ago by yawning

Cc: yawning added

comment:3 Changed 6 years ago by yawning

obfs4 is a go application, so it needs an extra patch to the TBB build process.

Working on that now, thanks to some pointers from dcf. The necessary changes look straight forward apart from some of the components I'm pulling in from the official golang google code repo sitting in hg instead of git. I'll probably just drop a bunch of tarballs in (directory name not final) or something unless someone has a better idea, past that I don't anticipate further difficulties assuming this build in a VM thing actually works.

comment:4 Changed 6 years ago by yawning

Ok, based off dcf's meek bundle repo, I did the build integration stuff.

Some notes:

  • I only tested linux builds, because I want my desktop back, windows/osx should work, but there may be minor errors where I copy/pasted things in the descriptors.
  • Ended up mirroring stuff in matching convention.
  • Dunno how the tbb people are going to decouple the go stuff in dcf's branch from meek if they want to only use obfs4.
  • I only edited versions.nightly, copy and pasting the changes is left as an exercise for the student, and applying the patch will break the other targets. Not sure what the procedure for "yeah, track master because I'm still working on it" is for versions, versions.alpha and versions.beta. obfs4proxy also only works with tor-0.2.5.x so building it with things other than nightly is a bit nonsensical at the moment.
  • obfs4proxy needs a LICENSE file that should eventually be copied.
  • I assume that if this gets deployed, I would want to move the code off github to somewhere.
  • The changes to the launcher to add "obfs4" as an option, and the change to torrc-defaults are left as an exercise for the student.
Version 0, edited 6 years ago by yawning (next)

Changed 6 years ago by yawning

Attachment: obfs4-bundle.diff added

Round 2, with windows fixed.

comment:5 Changed 6 years ago by yawning

obfs4 now lives at I haven't decided what to do with the github repository yet, I may just keep it around to use for staging.

When I have time I'll turn the obfs4-bundle.diff patch into a real branch since dcf's meek related changes got merged, but since I lost my build VM to the raid array in my desktop dying, this may be a while.

comment:6 Changed 6 years ago by dcf

Is there a "how to run an obfs4 bridge" doc, like

comment:7 Changed 6 years ago by yawning

Not yet, I was going to add a blurb to the README, although it won't be all that involved. The only differences in instructions are installing a different package (once such things exist), and

# Adjust the transports exposed to suit taste.
ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy

Optionally (since it's possible) people can setcap the obfs4proxy binary and do ServerTransportListenAddr obfs4 and the like, which I will also document.

master with updated documentation should end up being 0.0.1, unless I find something wrong within the next little while (or people report issues with the test bundles).

comment:8 Changed 6 years ago by isis

I've fixed #12932 and those changes will be available when BridgeDB-0.2.4 is deployed.

comment:9 Changed 6 years ago by libinhua2012

How to deploy a obfs4 bridge on my own debian system? Is there a instruction?

comment:10 Changed 6 years ago by asn

So, let me suggest to start deployment of obfs4, by merging this to tbb and using the 2 public bridges we already have?

After that, we have all the time in the world to get more bridges.

comment:11 Changed 6 years ago by isis

Cc: isis added
Keywords: bridgedb-pts added

comment:12 Changed 6 years ago by isis

I'm not sure when to enable obfs4 bridges for distribution in BridgeDB. We currently have 100+ obfs4 bridges, FWIW.

comment:13 in reply to:  12 Changed 6 years ago by asn

Replying to isis:

I'm not sure when to enable obfs4 bridges for distribution in BridgeDB. We currently have 100+ obfs4 bridges, FWIW.

Maybe we can do it when the first TBB that supports obfs4 appears?

I think this will be very soon (if it didn't happen this weekend).

comment:14 Changed 6 years ago by isis

Tor Browser 4.5.x-alphas have included obfs4 for a while now, and we've plenty of obfs4 bridges in BridgeDB. I've enabled it so that the alpha TB uses can better test obfs4. My changes to BridgeDB are in my fix/12130-obfs4 branch.

comment:15 Changed 6 years ago by isis

Keywords: bridgedb-0.2.4 added

comment:16 Changed 6 years ago by isis

Keywords: Isis2014Q3Q4 added

comment:17 Changed 6 years ago by isis

Keywords: isis2014Q3Q4 added; Isis2014Q3Q4 removed

comment:18 Changed 6 years ago by isis

Keywords: isis2015Q1Q2 added

comment:19 Changed 5 years ago by isis

Resolution: fixed
Status: newclosed

I think we can consider obfs4 fully deployed at this point, since it's included in TB as the default PT, and BridgeDB contains "many" obfs4 bridges.

Note: See TracTickets for help on using tickets.