Hi folks,
It looks like two of the default obfs3 bridges in Tor Browser have been broken for a while -- maybe for many months. I only noticed by accident today.
I was about to open a ticket for the Tor Browser team to automate checking them, so they can proactively notice and fix things if they break.
But then I thought, hey, OONI should be doing that testing from all over the world, right?
There are these tickets from the past: https://trac.torproject.org/projects/tor/ticket/12544 https://trac.torproject.org/projects/tor/ticket/6414
Maybe this is a great collaboration point between the Tor Browser team and the OONI team?
(For best collaboration, we might want to find a way to have it be more than the tor browser team saying "hey ooni, can you do this for us, thanks". :)
--Roger
On Sat, Nov 19, 2016 at 09:32:48PM -0500, Roger Dingledine wrote:
Hi folks,
It looks like two of the default obfs3 bridges in Tor Browser have been broken for a while -- maybe for many months. I only noticed by accident today.
I was about to open a ticket for the Tor Browser team to automate checking them, so they can proactively notice and fix things if they break.
But then I thought, hey, OONI should be doing that testing from all over the world, right?
There are these tickets from the past: https://trac.torproject.org/projects/tor/ticket/12544 https://trac.torproject.org/projects/tor/ticket/6414
There's also this recent ticket for reachability-only testing of default bridges: https://github.com/TheTorProject/ooni-probe/issues/652
On Sat, Nov 19, 2016 at 07:17:41PM -0800, David Fifield wrote:
There's also this recent ticket for reachability-only testing of default bridges: https://github.com/TheTorProject/ooni-probe/issues/652
Ah ha, right, your experiments with measuring blocking of default bridges totally tie into this one.
I think the things that I want beyond what you want are:
* Actually seeing if Tor works using the obfs bridge. In this case, the bridge address is accepting the TCP connection and then immediately hanging up -- it's like there's some proxy in front of the obfsproxy, so *something* answers, but it sure isn't obfsproxy. The goal here would be to learn if it's broken, rather than to learn if it's being interfered with, so maybe that will make measurement less complicated.
* I want the Tor Browser team to get involved with knowing how the tests work, knowing that they're happening, and having some way of noticing when the tests say that something has broken. Otherwise there will be knowledge inside some OONI data set somewhere that says a bridge stopped working, but we won't have anybody in place to close the loop and *do* something about it.
Though actually, there's some room for us to realize that it should instead be the Network team that steps in here. Or perhaps for both the Tor Browser team and the Network team to say that this topic isn't in their area. That outcome would be great to recognize and tackle too, since it needs to be in *somebody's* area.
--Roger
Roger Dingledine:
On Sat, Nov 19, 2016 at 07:17:41PM -0800, David Fifield wrote:
There's also this recent ticket for reachability-only testing of default bridges: https://github.com/TheTorProject/ooni-probe/issues/652
Ah ha, right, your experiments with measuring blocking of default bridges totally tie into this one.
I think the things that I want beyond what you want are:
- Actually seeing if Tor works using the obfs bridge. In this case,
the bridge address is accepting the TCP connection and then immediately hanging up -- it's like there's some proxy in front of the obfsproxy, so *something* answers, but it sure isn't obfsproxy. The goal here would be to learn if it's broken, rather than to learn if it's being interfered with, so maybe that will make measurement less complicated.
- I want the Tor Browser team to get involved with knowing how the tests
work, knowing that they're happening, and having some way of noticing when the tests say that something has broken. Otherwise there will be knowledge inside some OONI data set somewhere that says a bridge stopped working, but we won't have anybody in place to close the loop and *do* something about it.
I am fine with getting to know how those tests work and that they are happening. I think even getting a notice when something is broken is a good thing. But I don't think we (Tor Browser team) should be the ones hunting down folks to fix their bridges. Ideally the tests would show the bridge is not working anymore and the operator gets directly a notification about it. There should be no need to put the Tor Browser team or a member of any other team in the middle.
Though actually, there's some room for us to realize that it should instead be the Network team that steps in here. Or perhaps for both the Tor Browser team and the Network team to say that this topic isn't in their area. That outcome would be great to recognize and tackle too, since it needs to be in *somebody's* area.
Well, OONI seems to be in a good position to do the checking, if we want to do that.[1] The question is what happens afterwards, in case a bridge is down? As I said above notifying folks should not involve any other team than the one that did the measurement.
I am not sure yet what to do if we get a report that a default bridge is not working anymore and a Tor Browser release is about to get built. But maybe that case can get discussed and decided when we have reliable and continuous measurements and notifications in place.
Georg
[1] Ideally we would not need the measurement from anybody at all but the bridge operator would set up the respective infrastructure to get notified as soon as things are not working anymore. But I guess that would raise the bar for deploying a respective bridge considerably to the extent that we end up with less bridges we can ship in Tor Browser. Which is not desirable.
--Roger
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On 11/22/16 10:10, Georg Koppen wrote:
Roger Dingledine:
On Sat, Nov 19, 2016 at 07:17:41PM -0800, David Fifield wrote:
There's also this recent ticket for reachability-only testing of default bridges: https://github.com/TheTorProject/ooni-probe/issues/652
Ah ha, right, your experiments with measuring blocking of default bridges totally tie into this one.
I think the things that I want beyond what you want are:
- Actually seeing if Tor works using the obfs bridge. In this case,
the bridge address is accepting the TCP connection and then immediately hanging up -- it's like there's some proxy in front of the obfsproxy, so *something* answers, but it sure isn't obfsproxy. The goal here would be to learn if it's broken, rather than to learn if it's being interfered with, so maybe that will make measurement less complicated.
- I want the Tor Browser team to get involved with knowing how the tests
work, knowing that they're happening, and having some way of noticing when the tests say that something has broken. Otherwise there will be knowledge inside some OONI data set somewhere that says a bridge stopped working, but we won't have anybody in place to close the loop and *do* something about it.
I am fine with getting to know how those tests work and that they are happening. I think even getting a notice when something is broken is a good thing. But I don't think we (Tor Browser team) should be the ones hunting down folks to fix their bridges. Ideally the tests would show the bridge is not working anymore and the operator gets directly a notification about it. There should be no need to put the Tor Browser team or a member of any other team in the middle.
Though actually, there's some room for us to realize that it should instead be the Network team that steps in here. Or perhaps for both the Tor Browser team and the Network team to say that this topic isn't in their area. That outcome would be great to recognize and tackle too, since it needs to be in *somebody's* area.
Well, OONI seems to be in a good position to do the checking, if we want to do that.[1] The question is what happens afterwards, in case a bridge is down? As I said above notifying folks should not involve any other team than the one that did the measurement.
I am not sure yet what to do if we get a report that a default bridge is not working anymore and a Tor Browser release is about to get built. But maybe that case can get discussed and decided when we have reliable and continuous measurements and notifications in place.
Georg
[1] Ideally we would not need the measurement from anybody at all but the bridge operator would set up the respective infrastructure to get notified as soon as things are not working anymore. But I guess that would raise the bar for deploying a respective bridge considerably to the extent that we end up with less bridges we can ship in Tor Browser. Which is not desirable.
--Roger
I really like the idea and I agree OONI is in the best place to perform these tests.
Like Georg pointed out we have to think what to do once the test detect a bridge is not working. From the above I think we have two paths:
1. operator - we should notify the operator for sure, if we can do it in an automate way that would be great. If not, we should centralize such notifications in a place and have a person in charge of reviewing those and sending a note to the operator.
2. product - how the product should behave giving such information is another question. I believe the product should be smart enough to 'whitelist' the bridges it receives notifications from ooni that they are not working, so they are not counted as options for it to use until otherwise. Which leads to the need of sending another notification when they are working again.
Does this makes sense or I completely misunderstood everything! :D
Cheers, Isabela
On 22/11/2016 17:14 +0000, isabela wrote:
On 11/22/16 10:10, Georg Koppen wrote:
Roger Dingledine:
Ah ha, right, your experiments with measuring blocking of default bridges totally tie into this one.
I think the things that I want beyond what you want are:
- Actually seeing if Tor works using the obfs bridge. In this case,
the bridge address is accepting the TCP connection and then immediately hanging up -- it's like there's some proxy in front of the obfsproxy, so *something* answers, but it sure isn't obfsproxy. The goal here would be to learn if it's broken, rather than to learn if it's being interfered with, so maybe that will make measurement less complicated.
Yes I agree this would be useful, though we think the first step would be to just do a simple TCP connection scan. We are actually going to be pushing this test to all users of ooniprobe and we currently don't list obfsproxy (or obfs4proxy) as a hard dependency of ooniprobe which would be a requirement to have the full test run there.
We can change that in future version, but we should first do the simple thing so we can get it out soon and start being useful, rather than wait more to have something more fully featured.
This is part of the following ticket: https://github.com/TheTorProject/ooni-probe/issues/614
There are pending pull requests for adding testing via a simple TCP connect and we will be rolling this out as part of the 2.1.0 release due and the end of this month.
The relevant pull requests are: https://github.com/TheTorProject/ooni-probe/pull/682 https://github.com/OpenObservatory/ooni-resources/pull/1
Question for Tor Browser team: This is the list of bridges we are going to be testing as part of this first iteration: https://github.com/OpenObservatory/ooni-resources/pull/1/files#diff-4534a606...
This list is based on what David gave us to test and I think it includes most bridges from the current TBB (though it doesn't seem to include all obfs3 bridges) plus some other bridges that I believe you plan to start using in the future.
Is there something else you would like to have tested and added to this list?
- I want the Tor Browser team to get involved with knowing how the tests
work, knowing that they're happening, and having some way of noticing when the tests say that something has broken. Otherwise there will be knowledge inside some OONI data set somewhere that says a bridge stopped working, but we won't have anybody in place to close the loop and *do* something about it.
I am fine with getting to know how those tests work and that they are happening. I think even getting a notice when something is broken is a good thing. But I don't think we (Tor Browser team) should be the ones hunting down folks to fix their bridges. Ideally the tests would show the bridge is not working anymore and the operator gets directly a notification about it. There should be no need to put the Tor Browser team or a member of any other team in the middle.
Yes I agree that it would be great if we had some way of notifying bridge users directly, however we currently don't have support for notifications inside of our data processing pipeline.
It is something we have planned, but it will not be available immediately.
I guess we should understand what should be done based on these results once the first iteration is done.
Though actually, there's some room for us to realize that it should instead be the Network team that steps in here. Or perhaps for both the Tor Browser team and the Network team to say that this topic isn't in their area. That outcome would be great to recognize and tackle too, since it needs to be in *somebody's* area.
Well, OONI seems to be in a good position to do the checking, if we want to do that.[1] The question is what happens afterwards, in case a bridge is down? As I said above notifying folks should not involve any other team than the one that did the measurement.
I am not sure yet what to do if we get a report that a default bridge is not working anymore and a Tor Browser release is about to get built. But maybe that case can get discussed and decided when we have reliable and continuous measurements and notifications in place.
Something also to consider is that certain bridges may not be working only from specific locations. That is OONI tests will not just tell you if a bridge is DOWN, but will actually tell you in which countries a certain bridge is or is not working.
I wonder if it would make sense to at some point consider integrating this knowledge into Tor Browser itself. That is we could have some logic as part of tor launcher that makes the user input their country and depending on the country they input we know if we should advise them to use bridges (because we know vanilla tor to be blocked there) and if so which bridges are OK to be used there.
Georg
[1] Ideally we would not need the measurement from anybody at all but the bridge operator would set up the respective infrastructure to get notified as soon as things are not working anymore. But I guess that would raise the bar for deploying a respective bridge considerably to the extent that we end up with less bridges we can ship in Tor Browser. Which is not desirable.
--Roger
I really like the idea and I agree OONI is in the best place to perform these tests.
Like Georg pointed out we have to think what to do once the test detect a bridge is not working. From the above I think we have two paths:
- operator - we should notify the operator for sure, if we can do it in
an automate way that would be great. If not, we should centralize such notifications in a place and have a person in charge of reviewing those and sending a note to the operator.
My suggested step 0 is that we first get these measurements out and somebody looks at the results and checks to see how useful they are and actionable.
The concern here is that anything automated can potentially lead to false positives and we don't want to be flooding bridge operators with notices of things that are not necessarily true.
I also think that the monitoring of whether a bridge is up or down is slightly out of scope with what OONI does, though it's also something you can infer from the data as well if you take a certain vantage point, maybe one Tor sets up, to be unfiltered.
- product - how the product should behave giving such information is
another question. I believe the product should be smart enough to 'whitelist' the bridges it receives notifications from ooni that they are not working, so they are not counted as options for it to use until otherwise. Which leads to the need of sending another notification when they are working again.
Yes, I really like this idea!
I wrote some ideas on how I would see this work above.
Really looking forward to moving this ahead!
~ Arturo
If you make all the OONI instances test all the bridges... then when the Chinese firewall operator wants to know where all the current bridges are... they just have to run an OONI instance...?
John
On Wed, Nov 23, 2016 at 10:09:16AM -0800, John Gilmore wrote:
If you make all the OONI instances test all the bridges... then when the Chinese firewall operator wants to know where all the current bridges are... they just have to run an OONI instance...?
It's not *all* the bridges, just the few dozen default ones that are hardcoded into the source code of Tor Browser, the ones that are already easy to discover. Not the secret bridges from BridgeDB. The default bridges do get blocked eventually (only by the GFW, as far as we know), but they also sometimes break and nobody notices for a while.
Arturo Filastò:
On 22/11/2016 17:14 +0000, isabela wrote:
On 11/22/16 10:10, Georg Koppen wrote:
Roger Dingledine:
Ah ha, right, your experiments with measuring blocking of default bridges totally tie into this one.
I think the things that I want beyond what you want are:
- Actually seeing if Tor works using the obfs bridge. In this case,
the bridge address is accepting the TCP connection and then immediately hanging up -- it's like there's some proxy in front of the obfsproxy, so *something* answers, but it sure isn't obfsproxy. The goal here would be to learn if it's broken, rather than to learn if it's being interfered with, so maybe that will make measurement less complicated.
Yes I agree this would be useful, though we think the first step would be to just do a simple TCP connection scan. We are actually going to be pushing this test to all users of ooniprobe and we currently don't list obfsproxy (or obfs4proxy) as a hard dependency of ooniprobe which would be a requirement to have the full test run there.
We can change that in future version, but we should first do the simple thing so we can get it out soon and start being useful, rather than wait more to have something more fully featured.
This is part of the following ticket: https://github.com/TheTorProject/ooni-probe/issues/614
There are pending pull requests for adding testing via a simple TCP connect and we will be rolling this out as part of the 2.1.0 release due and the end of this month.
The relevant pull requests are: https://github.com/TheTorProject/ooni-probe/pull/682 https://github.com/OpenObservatory/ooni-resources/pull/1
Question for Tor Browser team: This is the list of bridges we are going to be testing as part of this first iteration: https://github.com/OpenObservatory/ooni-resources/pull/1/files#diff-4534a606...
This list is based on what David gave us to test and I think it includes most bridges from the current TBB (though it doesn't seem to include all obfs3 bridges) plus some other bridges that I believe you plan to start using in the future.
Is there something else you would like to have tested and added to this list?
That's quite a large list. What the Tor Browser team needs are the bridges specified in
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Da...
(which is subject to change). It seems your list is missing items from it.
- I want the Tor Browser team to get involved with knowing how the tests
work, knowing that they're happening, and having some way of noticing when the tests say that something has broken. Otherwise there will be knowledge inside some OONI data set somewhere that says a bridge stopped working, but we won't have anybody in place to close the loop and *do* something about it.
I am fine with getting to know how those tests work and that they are happening. I think even getting a notice when something is broken is a good thing. But I don't think we (Tor Browser team) should be the ones hunting down folks to fix their bridges. Ideally the tests would show the bridge is not working anymore and the operator gets directly a notification about it. There should be no need to put the Tor Browser team or a member of any other team in the middle.
Yes I agree that it would be great if we had some way of notifying bridge users directly, however we currently don't have support for notifications inside of our data processing pipeline.
It is something we have planned, but it will not be available immediately.
I guess we should understand what should be done based on these results once the first iteration is done.
Though actually, there's some room for us to realize that it should instead be the Network team that steps in here. Or perhaps for both the Tor Browser team and the Network team to say that this topic isn't in their area. That outcome would be great to recognize and tackle too, since it needs to be in *somebody's* area.
Well, OONI seems to be in a good position to do the checking, if we want to do that.[1] The question is what happens afterwards, in case a bridge is down? As I said above notifying folks should not involve any other team than the one that did the measurement.
I am not sure yet what to do if we get a report that a default bridge is not working anymore and a Tor Browser release is about to get built. But maybe that case can get discussed and decided when we have reliable and continuous measurements and notifications in place.
Something also to consider is that certain bridges may not be working only from specific locations. That is OONI tests will not just tell you if a bridge is DOWN, but will actually tell you in which countries a certain bridge is or is not working.
I wonder if it would make sense to at some point consider integrating this knowledge into Tor Browser itself. That is we could have some logic as part of tor launcher that makes the user input their country and depending on the country they input we know if we should advise them to use bridges (because we know vanilla tor to be blocked there) and if so which bridges are OK to be used there.
Maybe? I think this is definitely an idea worth thinking about.
Georg
[1] Ideally we would not need the measurement from anybody at all but the bridge operator would set up the respective infrastructure to get notified as soon as things are not working anymore. But I guess that would raise the bar for deploying a respective bridge considerably to the extent that we end up with less bridges we can ship in Tor Browser. Which is not desirable.
--Roger
I really like the idea and I agree OONI is in the best place to perform these tests.
Like Georg pointed out we have to think what to do once the test detect a bridge is not working. From the above I think we have two paths:
- operator - we should notify the operator for sure, if we can do it in
an automate way that would be great. If not, we should centralize such notifications in a place and have a person in charge of reviewing those and sending a note to the operator.
My suggested step 0 is that we first get these measurements out and somebody looks at the results and checks to see how useful they are and actionable.
Yes, indeed. Who should that somebody be (ideally)?
Georg
[snip]
On 25/11/2016 09:10 +0000, Georg Koppen wrote:
That's quite a large list. What the Tor Browser team needs are the bridges specified in
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Da...
(which is subject to change). It seems your list is missing items from it.
It seems like we are just missing from that list the obfs3 and fte bridges. Is it useful to also be testing those?
My suggested step 0 is that we first get these measurements out and somebody looks at the results and checks to see how useful they are and actionable.
Yes, indeed. Who should that somebody be (ideally)?
Well ideally it would be a person from either the Tor Browser or Network team.
~ Arturo
On Tue, Nov 29, 2016 at 11:00:49AM +0000, Arturo Filastò wrote:
On 25/11/2016 09:10 +0000, Georg Koppen wrote:
That's quite a large list. What the Tor Browser team needs are the bridges specified in
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Da...
(which is subject to change). It seems your list is missing items from it.
It seems like we are just missing from that list the obfs3 and fte bridges. Is it useful to also be testing those?
Yes, it's a good idea. For our experiment so far, we weren't really interested in protocols that could be dynamically active-probed; we included some of the the fte and obfs3 bridges just as known-blocked controls. But of course for other purposes you'll want to have the full list.
Apart from the missing fte and obfs3 bridges, the list Arturo has is a superset of bridge_prefs.js. In addition to the currently used addresses, it has some that were used in the past, or are waiting to be used in the future.
tor-project@lists.torproject.org
-
Arturo Filastò -
David Fifield -
Georg Koppen -
isabela -
John Gilmore -
Roger Dingledine