Hi,
In a recent connectivity test to the default obfs4 bridges [0], we found that we are unable to connect to 10 or so of them (from open networks, i.e., no local filtering).
Is this a feature, like some of them only respond to users in certain parts of the world? Or is this a bug, like the default list of bridges refers to old bridges that are no longer available? Or am I misunderstanding functionality here?
Thanks! Rob
[0] https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Da...
On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote:
In a recent connectivity test to the default obfs4 bridges [0], we found that we are unable to connect to 10 or so of them (from open networks, i.e., no local filtering).
Is this a feature, like some of them only respond to users in certain parts of the world? Or is this a bug, like the default list of bridges refers to old bridges that are no longer available? Or am I misunderstanding functionality here?
Do you mean 10 distinct IP addresses, or 10 ports on a few IP addresses? Not all the IP addresses in the list are distinct.
Even while Lynn Tsai, Qi Zhong, and I were closely monitoring default bridge reachability, a lot of the default bridges were often offline, because of reboots, iptables problems, etc. See for example the "Orbot bridges" strip of Figure 5.2 here; the gray and red areas that precede blocking are where the bridge was simply offline: https://www.bamsoftware.com/papers/thesis/fifield-thesis.pdf#page=43
We have a lot of past measurements of default bridges. The rows with site="eecs-login" are from the U.S. https://www.bamsoftware.com/proxy-probe/ (download the repo, not probe.csv.gz, which isn't as recent)
On Mar 28, 2018, at 12:23 PM, David Fifield david@bamsoftware.com wrote:
On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote:
In a recent connectivity test to the default obfs4 bridges [0], we found that we are unable to connect to 10 or so of them (from open networks, i.e., no local filtering).
Is this a feature, like some of them only respond to users in certain parts of the world? Or is this a bug, like the default list of bridges refers to old bridges that are no longer available? Or am I misunderstanding functionality here?
Do you mean 10 distinct IP addresses, or 10 ports on a few IP addresses? Not all the IP addresses in the list are distinct.
Turns out this was 10 ports on the same IP address. And we did the measurements back in December, so they are already a bit dated.
Even while Lynn Tsai, Qi Zhong, and I were closely monitoring default bridge reachability, a lot of the default bridges were often offline, because of reboots, iptables problems, etc. See for example the "Orbot bridges" strip of Figure 5.2 here; the gray and red areas that precede blocking are where the bridge was simply offline: https://www.bamsoftware.com/papers/thesis/fifield-thesis.pdf#page=43
We have a lot of past measurements of default bridges. The rows with site="eecs-login" are from the U.S. https://www.bamsoftware.com/proxy-probe/ (download the repo, not probe.csv.gz, which isn't as recent)
Ahh, this is great, thanks for sending!
Best, Rob
On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote:
Is this a feature, like some of them only respond to users in certain parts of the world? Or is this a bug, like the default list of bridges refers to old bridges that are no longer available? Or am I misunderstanding functionality here?
In general it's a bug. We don't have any fancy "only listen to this but not that" logic in those bridges.
I would totally believe that some of them are down by now. We need to do two things better: (a) monitor how they're doing, and (b) reach out to the operators when they go down, so the operators can fix them or so we can take them out of the next Tor Browser.
I think 'b' is where we've been falling down lately.
Maybe we should add this topic to the plate for the upcoming relay advocate.
--Roger
-
David Fifield -
Rob Jansen -
Roger Dingledine