Add dgoulet's obfs4 bridge to Tor Browser's default bridges

After the suggestion to remove #19714 (closed), dgoulet offered an obfs4 bridge as a default TB obfs4 bridge. The other obfs4 bridge operators have told me their bridges are saturated, so, provided that dgoulet's bridge can provide bandwidth similar to the others (see #18113 (moved) for how the round robining doesn't yet take bandwidth into account) then I propose we add it.

@dgoulet Could we get the bridge line for it privately (so that dcf can continue to run tests on how things are blocked)? Or, if you feel like it, you can patch it into Bundle-Data/PTConfigs/bridge_prefs.js in the tor-browser-bundle repo, and give one of the TB team the patch.

added TorBrowserTeam201611R component::applications/tor browser owner::tbb-team points::1 priority::very high resolution::fixed severity::normal status::closed tbb-bridges type::enhancement labels

Update: dcf requested that we have another bridge to add simultaneously for the sake of testing by what mechanism they are being blocked.

Replying to isis:

@dgoulet Could we get the bridge line for it privately (so that dcf can continue to run tests on how things are blocked)?

Lynn and I already got the bridge line from dgoulet and are testing its reachability.

@dcf, should I attach the diff on this ticket or should I give it to the TBB team? Asking so I don't reveal the bridge before being merged and thus adding a chance to "break" your testing?

Trac:
Status: new to needs_information

Replying to dgoulet:

@dcf, should I attach the diff on this ticket or should I give it to the TBB team? Asking so I don't reveal the bridge before being merged and thus adding a chance to "break" your testing?

Also, I'm not sure if TvdW emailed you, but I have details for a second bridge to go along with dgoulet's. Please tell me how/who to give it to, in keeping with the experiments.

Replying to isis:

Replying to dgoulet:

@dcf, should I attach the diff on this ticket or should I give it to the TBB team? Asking so I don't reveal the bridge before being merged and thus adding a chance to "break" your testing?

Also, I'm not sure if TvdW emailed you, but I have details for a second bridge to go along with dgoulet's. Please tell me how/who to give it to, in keeping with the experiments.

I guess send the bridge line to by encrypted email. We can start measuring it in advance. We might ask to preemptively forward some alternate ports in order to be able to change quickly if we have to.

@dcf: I just sent you the encrypted diff for TBB.

Update on where we're at with this: I want to send a summary of what we're doing to the new Tor Research Safety Board to get feedback on alternatives for using these bridges.

Trac:
Username: lynntsai

0001-Bug-19838-Adding-new-default-obfs4-bridge-Lisbeth.patch

Add new default bridges

Trac:
Username: lynntsai

We just attached the patch which adds David Goulet's bridge, Lisbeth. NX01 is currently commented out (intentionally) and we just asked tvdw to check it since we could not fully bootstrap to it. Don't merge this just yet until we hear back from tvdw that NX01 is working :)

Trac:
Username: lynntsai
Keywords: N/A deleted, tbb-bridges added

Trac:
Cc: dgoulet, isis, dcf, gk to dgoulet, isis, dcf, gk, info@tvdw.eu

Trac:
Username: lynntsai
Status: needs_information to needs_review
Keywords: N/A deleted, TorBrowserTeam201609R added

The patch looks good to me. Are we good to get this landed?

Trac:
Status: needs_review to needs_information

Yep! We're good to go -- NX01 has started working :)

Trac:
Username: lynntsai

It's good from my point of view too.

Alright, I applied the patch to master, maint-6.0 and hardened-builds (commit 7e0acfc779d22d5e4a1c5efdca9c75f082021f67, 585e546d589a89366a41ea54f268e703cdf89481, and 84cf9fff2adaf61e94c6f90e7e0c2ff3b04f7279).

Trac:
Status: needs_information to closed
Resolution: N/A to fixed

So after rebooting my server, the bridge stopped working and I realized after investigation that for some still unknown reason to me, it regenerated new keys.... changing the bridge line of course. I've since then restarted multiple time the machine and the daemon resulting in the bridge not regenerating again so it should be good.

Here is the new value (signed with my known GPG key):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Bridge obfs4 192.95.36.142:443 CDF2E852BF539B82BD10E27E9115A31734E378C2 cert=qUVQ0srL1JI/vO6V6m/24anYXiJD3QP2HgzUKQtQ7GRqqUvs7P+tG43RtAqdhLOALP7DJQ iat-mode=0
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCABmBQJYIMtFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCNzQ0MTdFRERGMjJBQzlGOUU5MEY0OTE0
MkU4NkEyQTExRjQ4RDM2AAoJEELoaioR9I02ZGwIAKTl5+eyxgJ0ox9thbHjypRe
LhXxCSzYWX52rqABVQnmQ+xV/HQCU11tL5aVAaJtPavMcfk/ppE0pMvt7YWcA+KL
Dr5Wia6rz0duOpzxPxiT0VssUd4RJktlSbR3WJcH5GxlX6N7wJq/lq47WLWSLREE
d+ixU70/FYtVugHzOYN4VK568Lda1kic3A0Kp7KfXkt+pLHeWP0hsiviQa6QISoq
aFIPhOn3dVrubjRUeCaj+YQvQR7T+JhkCPF7RYcPh3mxJH2cb1veNekw0OzbBuqQ
FpKTiKp5J2hAPHNosfHhJJM2FEQaGsWYWYhXxfg9l+IVq6CSTAg7IY0CEaw3vCo=
=j/Oq
-----END PGP SIGNATURE-----

Trac:
Resolution: fixed to N/A
Status: closed to reopened
Priority: Medium to Very High

Trac:
Keywords: TorBrowserTeam201609R deleted, TorBrowserTeam201611R added

Okay, I created a proper patch in my bug_19838 (https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_19838&id=6f0f3056e1cc896ee56ff03d5e306a672b17b75a). Anybody: please have a quick look as to whether I have messed that up.

The patch looks good to me.

Thanks. Applied the patch to master, maint-6.0 and hardened-builds (commits 6f0f3056e1cc896ee56ff03d5e306a672b17b75a, 08da98bfd734581660db11e0cc599a5a362fdccf and 0194cfb1ce4019d9d34ac3fa32a05ae242bd4c55).

Trac:
Status: reopened to closed
Resolution: N/A to fixed

closed

changed time estimate to 8h

mentioned in issue #20348 (moved)

mentioned in issue #20838 (moved)

moved to tpo/applications/tor-browser#19838 (closed)

mentioned in issue tpo/applications/tor-browser#20838 (closed)