bridge: Add Lisbeth IPv6 address

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

Turns out my obfs4 bridge in Tor Browser has an IPv6 so here it is:

Addr: 2001:470:b381:bfff:216:3eff:fe23:d6c3
Port: 443

Current bridge line for reference is:

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

iQEcBAEBCAAGBQJZLB6wAAoJEELoaioR9I02JMcH/1Sbyi6L+MgiKS0DZDHL53nl
VMKlGw/DdyOEy6zX+/W37Oyj6tQnWpoeo//JFlEqK6M/6Uf/WzQ+lPC0DRmQu7pu
n424WolCW+C9u+abb+CU6ETwdJPslRLpfiaM2VRl35gfu1Js+3GCKu7aeCmPRE9t
PUailXwHaWZIDRDfuNU0xeoa0nb1noGVebHIc0Yifd4DWAtLI6u3bQkSOv003alb
q+zsnC8JNyhz8DcWpguNXiT76RGAJYsPpSBrmAHovnmg1roQ0gkWDgQy470PruY0
7V3UX3OwzD7vznyUDNXpQ83nTjSe8RNpHZR3p+puo2yrYZcNGz62HzIe/jr1S9k=
=h1TJ
-----END PGP SIGNATURE-----

added TorBrowserTeam201706R component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-bridges type::enhancement labels

Trac:
Cc: N/A to dcf
Keywords: N/A deleted, tbb-bridges added

dcf: Do you have plans with the IPv6 address or can we just add that to the default bridges list? If the latter, would you mind writing the patch which I would then review and merge? That might be the fastest way to get this bug fixed.

Trac:
Status: new to needs_information

Trac:
0001-Bug-22429-Add-IPv6-address-for-Lisbeth-443-obfs4-bri.patch

Here is a patch. I tested the bridge line by itself in a torrc file, but I wasn't able to test it in Tor Browser on an IPv6-capable system.

When Tor Browser tries to use the bridge line on an IPv4-only system, this is what appears in the log:

06/01/2017 13:06:18.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 
06/01/2017 13:06:18.700 [NOTICE] Opening Socks listener on 127.0.0.1:9150 
06/01/2017 13:06:20.600 [NOTICE] Bootstrapped 5%: Connecting to directory server 
06/01/2017 13:06:20.600 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 
06/01/2017 13:06:20.600 [WARN] Proxy Client: unable to connect to 2001:470:b381:bfff:216:3eff:fe23:d6c3:443 ("general SOCKS server failure") 
06/01/2017 13:06:25.400 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150 
06/01/2017 13:06:25.400 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 
06/01/2017 13:06:25.400 [NOTICE] Closing old Socks listener on 127.0.0.1:9150 

Trac:
Status: needs_information to needs_review
Keywords: tbb-bridges deleted, tbb-bridges TorBrowserTeam201706R added

Replying to dcf:

Here is a patch. I tested the bridge line by itself in a torrc file, but I wasn't able to test it in Tor Browser on an IPv6-capable system.

When Tor Browser tries to use the bridge line on an IPv4-only system, this is what appears in the log: {{{ 06/01/2017 13:06:18.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 06/01/2017 13:06:18.700 [NOTICE] Opening Socks listener on 127.0.0.1:9150 06/01/2017 13:06:20.600 [NOTICE] Bootstrapped 5%: Connecting to directory server 06/01/2017 13:06:20.600 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 06/01/2017 13:06:20.600 [WARN] Proxy Client: unable to connect to 2001:470:b381:bfff:216:3eff:fe23:d6c3:443 ("general SOCKS server failure") 06/01/2017 13:06:25.400 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150 06/01/2017 13:06:25.400 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 06/01/2017 13:06:25.400 [NOTICE] Closing old Socks listener on 127.0.0.1:9150 }}}

Hrm. That's not good. I assume Tor Browser is randomly choosing one bridge the next time it starts (again) but we should be smarter here than making the user believe Tor Browser is broken. dcf: Do you know whether there is already a ticket anywhere for this issue?

Picked this up for now on master and maint-7.0 (commit 6dbe2e65a8d5822d024669e90d7f920b453adce4 and 94947a1c2333c4dcf0a0bf8af6228aceaf437ad2).

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

Replying to gk:

Replying to dcf:

Here is a patch. I tested the bridge line by itself in a torrc file, but I wasn't able to test it in Tor Browser on an IPv6-capable system.

When Tor Browser tries to use the bridge line on an IPv4-only system, this is what appears in the log: {{{ 06/01/2017 13:06:18.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 06/01/2017 13:06:18.700 [NOTICE] Opening Socks listener on 127.0.0.1:9150 06/01/2017 13:06:20.600 [NOTICE] Bootstrapped 5%: Connecting to directory server 06/01/2017 13:06:20.600 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 06/01/2017 13:06:20.600 [WARN] Proxy Client: unable to connect to 2001:470:b381:bfff:216:3eff:fe23:d6c3:443 ("general SOCKS server failure") 06/01/2017 13:06:25.400 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150 06/01/2017 13:06:25.400 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 06/01/2017 13:06:25.400 [NOTICE] Closing old Socks listener on 127.0.0.1:9150 }}}

Hrm. That's not good. I assume Tor Browser is randomly choosing one bridge the next time it starts (again) but we should be smarter here than making the user believe Tor Browser is broken. dcf: Do you know whether there is already a ticket anywhere for this issue?

When I did my test, I commented out all bridges except for the IPv6 one. I'm guessing it would have worked (with only a warning in the log) if I had left the others uncommented.

I don't know exactly how it works, but Tor Browser seems to choose more than one bridge. For example, in my browser right now, the log mentions GreenBelt, Azadi, MaBishomarim, cymrubridge31, Lisbeth, noether, cymrubridge33, NX01, ndnop5.

In the past, we had a separate fte-ipv6 option where the IPv6 addresses were kept. Those IPv6 bridges were removed in #18976 (moved).

Replying to dcf:

I don't know exactly how it works, but Tor Browser seems to choose more than one bridge. For example, in my browser right now, the log mentions GreenBelt, Azadi, MaBishomarim, cymrubridge31, Lisbeth, noether, cymrubridge33, NX01, ndnop5.

The design as I understood it (hopefully it hasn't changed) is that when you choose a class of bridges, Tor Browser tells Tor about all of those bridges, and then it's up to Tor to use them smartly.

Tor tries to fetch a descriptor from each bridge every 15 minutes or something, to keep up to date. Separate from that, it tries to use the entry guard algorithm to focus its 3-hop circuits on only one or a few of the bridges.

So you should see descriptor refresh messages for each bridge every so often, or failure messages if there's something wrong with the bridge, for every bridge that Tor Browser tells Tor.

Trac:

Trac:
tor-bridge-ipversion.tar.gz

Here's a graph showing IPv4 and IPv6 connections to Lisbeth. The Tor Browser releases that added Lisbeth's addresses are marked: 6.0.6 for IPv4 and 7.0 for IPv6. It's just showing the bridge-ip-versions line from bridge-extra-info documents. I don't know what explains the bump in IPv6 in August 2017.

source code: tor-bridge-ipversion.tar.gz​

closed

mentioned in issue #22468 (moved)

mentioned in issue #22470 (closed)

mentioned in issue #22470 (closed)

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