Are there any roadblocks that prevent us from doing the following?
1. Remove the hard-coded bridge_prefs.js in the TBB. 2. Set meek as the default pluggable transport in the TBB. 3. Use meek to acquire an up-to-date bridge_prefs.js from, say, torproject.org. 4. Use the information from the acquired bridge_prefs.js to connect to Tor as normal.
Ostensibly, this doesn't do a better job of hiding bridge addresses. However, it allows us to modify bridge addresses without releasing a new TBB.
-Kevin
On Sat, Jul 26, 2014 at 03:08:38PM +0100, Kevin P Dyer wrote:
Are there any roadblocks that prevent us from doing the following?
- Remove the hard-coded bridge_prefs.js in the TBB.
- Set meek as the default pluggable transport in the TBB.
- Use meek to acquire an up-to-date bridge_prefs.js from, say,
torproject.org. 4. Use the information from the acquired bridge_prefs.js to connect to Tor as normal.
Flash proxy does something similar when it starts up and does rendezvous. The helper program flashproxy-reg-appspot uses the meek domain fronting trick (but simpler) to find out its own IP and send it to the facilitator. You wouldn't actually need to fire up meek; you could just front an HTTPS GET request for the document you need.
https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/flashproxy-reg-a... https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/flashproxy-reg-appsp...
I don't know that you'd want to rely on it entirely--meek over App Engine doesn't work in China and we haven't deployed any other backends yet. Nothing is ever going to be as reliable as a file you already have on disk.
I supose this is because you want to make FTE bridges dynamic?
David Fifield
On Sat, Jul 26, 2014 at 5:30 PM, David Fifield david@bamsoftware.com wrote:
On Sat, Jul 26, 2014 at 03:08:38PM +0100, Kevin P Dyer wrote:
Are there any roadblocks that prevent us from doing the following?
- Remove the hard-coded bridge_prefs.js in the TBB.
- Set meek as the default pluggable transport in the TBB.
- Use meek to acquire an up-to-date bridge_prefs.js from, say,
torproject.org. 4. Use the information from the acquired bridge_prefs.js to connect to
Tor as
normal.
Flash proxy does something similar when it starts up and does rendezvous. The helper program flashproxy-reg-appspot uses the meek domain fronting trick (but simpler) to find out its own IP and send it to the facilitator. You wouldn't actually need to fire up meek; you could just front an HTTPS GET request for the document you need.
https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/flashproxy-reg-a...
https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/flashproxy-reg-appsp...
I don't know that you'd want to rely on it entirely--meek over App Engine doesn't work in China and we haven't deployed any other backends yet.
Is App Engine blocked in China?
Nothing is ever going to be as reliable as a file you already have on disk.
We could have a file on disk as a fallback option, right?
I supose this is because you want to make FTE bridges dynamic?
Exactly.
-Kevin
On Sat, Jul 26, 2014 at 06:11:45PM +0100, Kevin P Dyer wrote:
Is App Engine blocked in China?
All Google services are blocked in China since May 31.
https://en.greatfire.org/blog/2014/jun/google-disrupted-prior-tiananmen-anni... https://www.google.com/transparencyreport/traffic/disruptions/124/
From what I gather, GoAgent is still working, but only for those who are
able to find a Google Global Cache IP (some kind of Google CDN). I don't know of a way to automate it.
https://code.google.com/p/goagent/issues/list?can=2&q=GGC&colspec=ID... https://code.google.com/p/goagent/issues/detail?id=14732
David Fifield
On Sat, 26 Jul 2014 15:08:38 +0100 Kevin P Dyer kpdyer@gmail.com wrote:
Are there any roadblocks that prevent us from doing the following?
- Remove the hard-coded bridge_prefs.js in the TBB.
Ok.
- Set meek as the default pluggable transport in the TBB.
Sure that's also fairly easy.
- Use meek to acquire an up-to-date bridge_prefs.js from, say,
torproject.org.
Whowa, what? I get (from other parts of the thread) that there are compelling reasons for this, but I can think of at least two reasons why I would be massively against this.
a) Who is going to pay for this? The amount of data transferred will grow to be non-trivial rather quickly because each user that ends up doing this will do the full bootstrap. Granted, this will be a one time thing per bundle release (and a one time thing over the lifespan of the client in some magical world where TBB has an update mechanism), so the economic side in the future isn't quite as dire, but still.
b) Giving anyone a list of a subset of our users (and a particularly vulnerable subset at that, since they need to use PTs), seems dangerous at best. Going from "all meek users need to trust $CDN" to "the default behavior is to give $CDN a list of anyone trying to use PTs" at first glance seems like something that will only end badly.
- Use the information from the acquired bridge_prefs.js to connect
to Tor as normal.
No clue as to how hard this is.
Ostensibly, this doesn't do a better job of hiding bridge addresses. However, it allows us to modify bridge addresses without releasing a new TBB.
I don't see that as being a sufficiently compelling reason to give a third party the ability to enumerate (a unknown fraction of) the PT user base (while making them rich at the same time).
Regards,
-
David Fifield -
Kevin P Dyer -
Yawning Angel