Make bundles featuring meek
Let's try out some bundles with [[doc/meek|meek]].
Activity
Replying to asn:
d) Make its TLS layer less easily fingerpintable.
This is my thinking on [[doc/meek#Distinguishability|HTTPS fingerprintability]] and deployment. We should first take care of the trivial fingerprinting issues, namely client ciphersuites and TLS extensions, and then make the first deployment. Those two are the things for which a firewall rule can be written in five minutes. The other issues are things like traffic statistics, which are important but not immediately important in that it takes time to make a classifier and even then it's not 100%.
I'm working on a TBB browser extension to make HTTPS requests on behalf of meek-client. That will get us Firefox's ciphersuites and TLS extensions, and I think is more realistically deployable than, say, packaging another browser in the TBB, and more future-proof than writing a custom OpenSSL or NSS program that closely tries to imitate browser TLS.
Replying to dcf:
I'm working on a TBB browser extension to make HTTPS requests on behalf of meek-client. That will get us Firefox's ciphersuites and TLS extensions, and I think is more realistically deployable than, say, packaging another browser in the TBB, and more future-proof than writing a custom OpenSSL or NSS program that closely tries to imitate browser TLS.
#11183 (moved) is the ticket for a browser extension.
Replying to asn:
b) Get someone to run a stable/fast meek bridge.
A big consideration here is latency; i.e., proximity to App Engine servers. We're adding an extra roundtrip hop to every communication: meek-client → App Engine → meek-server We have no control over the meek-client→App Engine link, but we can try to make the App Engine→meek-server link fast.
Here are sample roundtrip times for a few servers. The test is running live at http://meek-latency-test.appspot.com/. Source code for the test is in the repo here. The horizontal axis is milliseconds.
The measured servers are in order:
- my bridge in California (the same one used for flash proxy)
- my bridge with HTTPS turned on
- a bridge in Greece
- a Google server very close to App Engine (lower bound on roundtrip time)
- an HTTPS Google server very close to App Engine (lower bound on HTTPS roundtrip time) I can add other servers if someone wants to test their own.
It appears that the App Engine requests are coming from 8.35.201.0/24 in the U.S. This link seems to confirm that the servers are in the U.S. Ideally we minimize latency with that netblock.
All that said, I've been using the Greek bridge for a while, and it doesn't feel that slow, but maybe I'm just used to it.
Replying to asn:
c) Figure out if Tor can pay the Appengine bills.
Google is currently offering $500 in Cloud Platform credit. (Cloud Platform includes App Engine.) I applied, describing meek, and received a code for $500.
It says the credit expires three months after it is redeemed. My guess is that we'll use up the three months before we use up the $500. So I think to activate the credit just before public deployment. That should keep us running for three months anyway.
- https://lists.torproject.org/pipermail/tor-qa/2014-April/000390.html
- https://people.torproject.org/~dcf/pt-bundle/3.5.4-meek-1/
- https://gitweb.torproject.org/pluggable-transports/meek.git/tag/refs/tags/0.4
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/tag/refs/tags/tbb-3.5.4-meek-1
These bundles use a browser extension for TLS camouflage. We're now very close to where we want to be for a test release. I need to make a rebased merge branch of https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/heads/meek and add meek to the tor launcher config (#11488 (moved)). George said he'd try the bundles and look at the source code.
I still have not read the source code.
I tested the linux64 bundle yesterday night. It worked great. I wouldn't even notice the second browser, if I hadn't done a
pstree, that looks like this:├─sh───rxvt-unicode─┬─bash───start-tor-brows───firefox─┬─tor───meek-client-tor─┬─firefox─┬─firefox │ │ │ │ ├─{Cache I/O} │ │ │ │ ├─{Cert Verify} │ │ │ │ ├─{DOM Worker} │ │ │ │ ├─{Gecko_IOThread} │ │ │ │ ├─{Hang Monitor} │ │ │ │ ├─{JS GC Helper} │ │ │ │ ├─{JS Sour~ Thread} │ │ │ │ ├─{JS Watchdog} │ │ │ │ ├─{Proxy R~olution} │ │ │ │ ├─{Socket Thread} │ │ │ │ ├─{Timer} │ │ │ │ └─{mozStorage #1} │ │ │ ├─meek-client───5*[{meek-client}] │ │ │ └─4*[{meek-client-tor}] │ │ ├─3*[{Analysis Helper}] │ │ ├─{Cache I/O} │ │ ├─{Cert Verify} │ │ ├─2*[{DOM Worker}] │ │ ├─{Gecko_IOThread} │ │ ├─{HTML5 Parser} │ │ ├─{Hang Monitor} │ │ ├─{JS GC Helper} │ │ ├─{JS Sour~ Thread} │ │ ├─{JS Watchdog} │ │ ├─{MediaManager} │ │ ├─{Proxy R~olution} │ │ ├─{RunProcess} │ │ ├─{Socket Thread} │ │ ├─{Timer} ...I didn't test with wireshark to see if the SSL looks firefoxy. I need to do that next.
Also, with the meek bundles, on Tor bootstrap I always get the following error:
Apr 12 14:26:46.000 [warn] Received http status code 404 ("Not found") from server '0.0.2.0:1' while fetching "/tor/keys/fp-sk/27B6B5996C426270A5C95488AA5BCEB6BCC86956-510628E039BC57EB78FD5A324E995690C1BDF1CE".I'm not sure why I would get this error.
https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/tbb-3.5.4-meek-1?hp=tbb-3.5.4-build3 looks good. Just one thing: you write
# A PIE build fails on amd64 in cgo tests.If that is really only an amd64 issue could you then disable the hardening just on that architecture? GBUILD_BITS is your friend here.
Replying to gk:
https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/tbb-3.5.4-meek-1?hp=tbb-3.5.4-build3 looks good. Just one thing: you write {{{
A PIE build fails on amd64 in cgo tests.
}}} If that is really only an amd64 issue could you then disable the hardening just on that architecture? GBUILD_BITS is your friend here.
I tried it again without disabling DEB_BUILD_HARDENING_PIE, and didn't get an error. I'm going to test some bundles that don't touch DEB_BUILD_HARDENING_PIE at all.
In any case, I don't think PIE is going to buy us anything with golang executables. https://code.google.com/p/go/issues/detail?id=6940#c6: "The Go linker does not currently support building objects that may be linked into a PIE."
3.6.1-meek-1 bundles:
- https://people.torproject.org/~dcf/pt-bundle/3.6.1-meek-1/
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/heads/tbb-3.6.1-meek-1 The big change in this version is that meek is no longer activated by default; you have to configure it like any other transport (as shown at [[doc/meek#Quickstart]]).
I also prepared a parallel rebased merge candidate branch. It has just 8 commits on top of tbb-3.6.1-build1. The second link shows all the changes made in the branch.
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/heads/meek-rebase-3.6.1
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/meek-rebase-3.6.1?hp=tbb-3.6.1-build1
Trac:
Status: assigned to needs_reviewThe question came up of how much meek increases the size of the bundles. I compared 3.6.1-meek-1 with 3.6.1 and the summary is:
- 1.7 MB increase in linux xz (29 MB to 31 MB)
- 1.9 MB increase in windows exe (26 MB to 28 MB)
- 2.4 MB increase in mac dmg (31 MB to 33 MB)
The increase is almost entirely caused by new executables: the size of the extra Firefox profile and extension, documentation, etc. is negligible.
Here's a list of all the added files in the linux bundle with their sizes:
967 ./Data/Browser/profile.meek-http-helper/user.js 2.9K ./Docs/meek/README 3.0K ./Docs/meek/meek-server.1 4.1K ./Docs/meek/meek-client.1 5.5K ./Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi 6.9K ./Docs/PluggableTransports/LICENSE.CC0 3.5M ./Tor/PluggableTransports/meek-client-torbrowser 7.6M ./Tor/PluggableTransports/meek-clientClearly the two programs meek-client-torbrowser and meek-client are the only files that matter. On disk they are 11.2 MB together. When I compress them with xz, they take up 1.7 MB.
1.7M t.tar.xzThe large size of the binaries is caused by static linking by the golang compiler. I don't think we want to try to circumvent Go's preference for static linking (see e.g. http://harmful.cat-v.org/software/dynamic-linking/); compression seems to get rid of most of the redundancy anyway. The large executable sizes are a known problem; see issue 6853: binaries too big and growing and Go Binary Sizes Are Growing out of Control. It's supposed to be better in the upcoming Go 1.3 (we're using Go 1.2). I tried compiling with a 1.3 beta and it does save some bytes, though compression makes it not matter much: With Go 1.2:
3.5M ./Tor/PluggableTransports/meek-client-torbrowser 7.6M ./Tor/PluggableTransports/meek-client ---- 1.7M t.tar.xzWith Go 1.3:
2.8M ./Tor/PluggableTransports/meek-client-torbrowser 6.0M ./Tor/PluggableTransports/meek-client ---- 1.6M t.tar.xzAppendix
For the record, here are the exact bundle sizes of 3.6.1 and 3.6.1-meek-1:
30021204 tor-browser-linux64-3.6.1_en-US.tar.xz 31790408 tor-browser-linux64-3.6.1-meek-1_en-US.tar.xz 26949533 torbrowser-install-3.6.1_en-US.exe 28954030 torbrowser-install-3.6.1-meek-1_en-US.exe 31522646 TorBrowser-3.6.1-osx32_en-US.dmg 34053808 TorBrowser-3.6.1-meek-1-osx32_en-US.dmgHere are the added files and their sizes for windows (missing doc files are #11834 (closed)). The extra terminateprocess-buffer.exe program is a special program required only on windows. I derived this output from
diff -u <(cd 3.6.1/windows && find . -type f -print0 | xargs -0 ls -lh) <(cd 3.6.1-meek-1/windows && find . -type f -print0 | xargs -0 ls -lh).967 ./$_OUTDIR/Data/Browser/profile.meek-http-helper/user.js 5.5K ./$_OUTDIR/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi 6.9K ./$_OUTDIR/Docs/PluggableTransports/LICENSE.CC0 2.2M ./$_OUTDIR/Tor/PluggableTransports/terminateprocess-buffer.exe 2.7M ./$_OUTDIR/Tor/PluggableTransports/meek-client-torbrowser.exe 5.8M ./$_OUTDIR/Tor/PluggableTransports/meek-client.exeAgain compression of the executables accounts for essentially all the difference in bundle sizes.
2.2M ./$_OUTDIR/Tor/PluggableTransports/terminateprocess-buffer.exe 2.7M ./$_OUTDIR/Tor/PluggableTransports/meek-client-torbrowser.exe 5.8M ./$_OUTDIR/Tor/PluggableTransports/meek-client.exe ---- 1.8M t.7zHere are the added files and their sizes for mac (missing doc files are 9d611fde).
967 ./TorBrowser.app/Data/Browser/profile.meek-http-helper/user.js 5.5K ./TorBrowser.app/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi 6.9K ./TorBrowser.app/Docs/PluggableTransports/LICENSE.CC0 2.8M ./TorBrowser.app/Tor/PluggableTransports/meek-client-torbrowser 6.2M ./TorBrowser.app/Tor/PluggableTransports/meek-clientThe bz2 compression of the dmg container doesn't save as much in this case.
2.8M ./TorBrowser.app/Tor/PluggableTransports/meek-client-torbrowser 6.2M ./TorBrowser.app/Tor/PluggableTransports/meek-client ---- 2.5M t.tar.bz2-
Replying to dcf:
I also prepared a parallel rebased merge candidate branch. It has just 8 commits on top of tbb-3.6.1-build1. The second link shows all the changes made in the branch.
This looks good to me. Bonus points if you could get rid of these sudo calls (might be a matter of setting $PATH properly). I am currently refactoring the descriptors and getting everything to work without the need for special privileges while building is one (albeit very minor) goal.
3.6.1-meek-2 bundles:
- https://people.torproject.org/~dcf/pt-bundle/3.6.1-meek-2/
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/tags/tbb-3.6.1-meek-2 The only change is a fix for #11429 (moved), so you no longer get a second dock icon on mac.
I'll do another rebase on 3.6.2 when that's released, hopefully also including the proxy stuff from #12120 (moved).
Replying to gk:
Replying to dcf:
I also prepared a parallel rebased merge candidate branch. It has just 8 commits on top of tbb-3.6.1-build1. The second link shows all the changes made in the branch.
This looks good to me. Bonus points if you could get rid of these sudo calls (might be a matter of setting $PATH properly). I am currently refactoring the descriptors and getting everything to work without the need for special privileges while building is one (albeit very minor) goal.
I got rid of sudo in cc40318a2268e3d8b4ad80002445465e76472a5c.
3.6.2-meek-1:
- https://people.torproject.org/~dcf/pt-bundle/3.6.2-meek-1/
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/tags/tbb-3.6.2-meek-1
- https://lists.torproject.org/pipermail/tor-qa/2014-June/000422.html
They are built not exactly on top of the 3.6.2 bundles, because I merged with the tag tbb-3.6.2-build5 and the 3.6.2 bundles were apparently built with what is now the head of maint-3.6.
I also have a rebased branch, which I propose for merge:
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/refs/heads/meek-rebase-3.6.2
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/refs/heads/meek-rebase-3.6.2?hp=tbb-3.6.2-build5 The main noteworthy change since the [[comment:14|last rebase branch]] is the addition of a shallow copy of TorBrowser.app with a modified Info.plist file. The reason for it is in #11429 (moved); it's to prevent two icons from appearing on OS X. I tried an alternative idea, hiding the icons with js-ctypes from the extension itself, but it creates [[comment:9:ticket:11429|a race]] between the dock trying to show the icon and the extension trying to hide it.
I know that #11641 (closed) changes the directory structure, which will probably affect the Info.plist thing. Would you like me to rebase somewhere onto master, rather than the maint-3.6 branch?
Trac:
Keywords: meek deleted, meek MikePerry201406R addedReplying to gk:
You want to add the verification of GO as well in the verify-tags.sh script (as you did in the fetch-inputs.sh script).
Thanks, I missed that. Done in 23085a6b37bb0c1887223e7f5ddef458a18ba613.
Did you test with a different Gitian setup to check whether building meek is still reproducible?
I tried building it again, and ran into the trouble in #12382 (closed). However the packages are the same except for the changed langpack files. The en-US packages are identical.
-
Replying to dcf:
I know that #11641 (closed) changes the directory structure, which will probably affect the Info.plist thing. Would you like me to rebase somewhere onto master, rather than the maint-3.6 branch?
Yes, please. We plan to release a 4.0 alpha which could contain meek to give it a wider testing (and test its reproducibility under release conditions).
Replying to gk:
Replying to dcf:
I know that #11641 (closed) changes the directory structure, which will probably affect the Info.plist thing. Would you like me to rebase somewhere onto master, rather than the maint-3.6 branch?
Yes, please. We plan to release a 4.0 alpha which could contain meek to give it a wider testing (and test its reproducibility under release conditions).
I started the rebase, but the build hasn't finished, and now I won't be able to finish it until June 19. Please stand by.
Replying to gk:
Yes, please. We plan to release a 4.0 alpha which could contain meek to give it a wider testing (and test its reproducibility under release conditions).
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/refs/heads/meek-rebase-4.0-alpha1-pre
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/refs/heads/meek-rebase-4.0-alpha1-pre?hp=5b4c3fe36ce264f7547d7713073876ecedb51e58
I tested it and made sure it would bootstrap with meek on all platforms.
I put the second headless app (#11429 (moved)) under TorBrowser/Data/TorBrowser.app.meek-http-helper. It has symlinks to the top-level Contents files, and modified Info.plist.
Here's a summary of added files on every platform.
linux32/64:
+Browser/TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi +Browser/TorBrowser/Data/Browser/profile.meek-http-helper/user.js +Browser/TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0 +Browser/TorBrowser/Docs/meek/meek-client.1 +Browser/TorBrowser/Docs/meek/meek-server.1 +Browser/TorBrowser/Docs/meek/README +Browser/TorBrowser/Tor/PluggableTransports/meek-client +Browser/TorBrowser/Tor/PluggableTransports/meek-client-torbrowserwindows:
+Browser/TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi +Browser/TorBrowser/Data/Browser/profile.meek-http-helper/user.js +Browser/TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0 +Browser/TorBrowser/Docs/meek/meek-client.1.txt +Browser/TorBrowser/Docs/meek/meek-server.1.txt +Browser/TorBrowser/Docs/meek/README +Browser/TorBrowser/Tor/PluggableTransports/meek-client.exe +Browser/TorBrowser/Tor/PluggableTransports/meek-client-torbrowser.exe +Browser/TorBrowser/Tor/PluggableTransports/terminateprocess-buffer.exemac:
+Docs/meek +Docs/meek/meek-client.1 +Docs/meek/meek-server.1 +Docs/meek/README +TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi +TorBrowser/Data/Browser/profile.meek-http-helper/user.js +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Info.plist +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/MacOS +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/PkgInfo +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Resources +TorBrowser/Data/TorBrowser.app.meek-http-helper/README +TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0 +TorBrowser/Tor/PluggableTransports/meek-client +TorBrowser/Tor/PluggableTransports/meek-client-torbrowser-
This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?
Trac:
Cc: N/A to mcs, brade Replying to gk:
This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?
I didn't even notice the wrong placement of the meek docs. That's a bug. I'll put it under TorBrowser/Docs like in the other cases.
Take 2, with mac docs in the right place.
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/refs/heads/meek-rebase-4.0-alpha1-pre-take2
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/refs/heads/meek-rebase-4.0-alpha1-pre-take2?hp=5b4c3fe36ce264f7547d7713073876ecedb51e58
Difference from previous branch:
The mac file diff is now
+TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi +TorBrowser/Data/Browser/profile.meek-http-helper/user.js +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Info.plist +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/MacOS +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/PkgInfo +TorBrowser/Data/TorBrowser.app.meek-http-helper/Contents/Resources +TorBrowser/Data/TorBrowser.app.meek-http-helper/README +TorBrowser/Docs/Licenses/PluggableTransports/LICENSE.CC0 +TorBrowser/Docs/meek +TorBrowser/Docs/meek/meek-client.1 +TorBrowser/Docs/meek/meek-server.1 +TorBrowser/Docs/meek/README +TorBrowser/Tor/PluggableTransports/meek-client +TorBrowser/Tor/PluggableTransports/meek-client-torbrowser
Replying to gk:
This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?
I discussed this with Kathy. It seems a little odd to place an application bundle (even a symlink'd one) under TorBrowser/Data. Maybe move it under TorBrowser/Tor/PluggableTransports/ ?
Also, maybe it is intentional or maybe not that the bundle does not end in .app, but we would have expected to see a name like TorBrowser-meek-http-helper.app. Apparently things work either way though.
The other issue that we will need to research is whether the Firefox updater (#4234 (moved)) can handle symlinks. My guess is that it cannot but maybe we will be pleasantly surprised ;) I think we have to proceed with the symlinks for now in the interest of getting the alpha out.
Replying to mcs:
Replying to gk:
This looks good to me. The only thing I am not sure is wrt the location for the headless app and the placement of Docs/meek in the OS X case. Let's see what Kathy/Mark are saying. Kathy/Mark: Could you comment on those things? Does there something speak against the current idea? If so, what would be a better place?
I discussed this with Kathy. It seems a little odd to place an application bundle (even a symlink'd one) under TorBrowser/Data. Maybe move it under TorBrowser/Tor/PluggableTransports/ ?
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/refs/heads/meek-rebase-4.0-alpha1-pre-take3
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/refs/heads/meek-rebase-4.0-alpha1-pre-take3?hp=5b4c3fe36ce264f7547d7713073876ecedb51e58
- https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/refs/heads/meek-rebase-4.0-alpha1-pre-take3?hp=refs/heads/meek-rebase-4.0-alpha1-pre-take2
Also, maybe it is intentional or maybe not that the bundle does not end in .app, but we would have expected to see a name like TorBrowser-meek-http-helper.app. Apparently things work either way though.
I avoided ending the file name with ".app" to reduce the likelihood that a curious user would launch the internal bundle by double-clicking. The internal bundle is necessarily configured to bypass the Tor proxy, so it's dangerous if it's confused with the actual Tor Browser. The naming trick worked when it was under TorBrowser/Data (the app appeared as a normal folder), but for some reason it doesn't work under TorBrowser/Tor/PluggableTransports :/ When you double-click the icon, first you get a dialog offering to import your bookmarks, then you get a browser window with the normal Firefox branding. You can't type into it, nor does it appear in the dock, probably because of the LSBackgroundOnly setting.
-
Replying to dcf:
I avoided ending the file name with ".app" to reduce the likelihood that a curious user would launch the internal bundle by double-clicking. The internal bundle is necessarily configured to bypass the Tor proxy, so it's dangerous if it's confused with the actual Tor Browser. The naming trick worked when it was under TorBrowser/Data (the app appeared as a normal folder), but for some reason it doesn't work under TorBrowser/Tor/PluggableTransports :/ When you double-click the icon, first you get a dialog offering to import your bookmarks, then you get a browser window with the normal Firefox branding. You can't type into it, nor does it appear in the dock, probably because of the LSBackgroundOnly setting.
Almost certainly the app copy does not know where to find its browser profile. I think you have a reasonable point about not wanting users to be tempted to open the app, so not ending in .app makes sense.
Replying to dcf:
It appears that the App Engine requests are coming from 8.35.201.0/24 in the U.S. This link seems to confirm that the servers are in the U.S. Ideally we minimize latency with that netblock.
Here's the official way to get the App Engine IPs:
$ nslookup -q=TXT _cloud-netblocks.googleusercontent.com 8.8.8.8 _cloud-netblocks.googleusercontent.com text = "v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_cloud-netblocks2.googleusercontent.com include:_cloud-netblocks3.googleusercontent.com ?all" $ nslookup -q=TXT _cloud-netblocks1.googleusercontent.com 8.8.8.8 _cloud-netblocks1.googleusercontent.com text = "v=spf1 ip4:8.34.208.0/20 ip4:8.35.192.0/21 ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4:108.170.208.0/21 ip4:108.170.216.0/22 ip4:108.170.220.0/23 ip4:108.170.222.0/24 ?all" $ nslookup -q=TXT _cloud-netblocks2.googleusercontent.com 8.8.8.8 _cloud-netblocks2.googleusercontent.com text = "v=spf1 ip4:162.216.148.0/22 ip4:162.222.176.0/21 ip4:173.255.112.0/20 ip4:192.158.28.0/22 ip4:199.192.112.0/22 ip4:199.223.232.0/22 ip4:199.223.236.0/23 ip4:23.236.48.0/20 ip4:23.251.128.0/19 ?all" $ nslookup -q=TXT _cloud-netblocks3.googleusercontent.com 8.8.8.8 _cloud-netblocks3.googleusercontent.com text = "v=spf1 ip4:107.167.160.0/19 ip4:107.178.192.0/18 ip4:146.148.2.0/23 ip4:146.148.4.0/22 ip4:146.148.8.0/21 ip4:146.148.16.0/20 ip4:146.148.32.0/19 ip4:146.148.64.0/18 ip4:130.211.4.0/22 ?all"- 8.34.208.0/20
- 8.35.192.0/21
- 8.35.200.0/23
- 108.59.80.0/20
- 108.170.192.0/20
- 108.170.208.0/21
- 108.170.216.0/22
- 108.170.220.0/23
- 108.170.222.0/24
- 162.216.148.0/22
- 162.222.176.0/21
- 173.255.112.0/20
- 192.158.28.0/22
- 199.192.112.0/22
- 199.223.232.0/22
- 199.223.236.0/23
- 23.236.48.0/20
- 23.251.128.0/19
- 107.167.160.0/19
- 107.178.192.0/18
- 146.148.2.0/23
- 146.148.4.0/22
- 146.148.8.0/21
- 146.148.16.0/20
- 146.148.32.0/19
- 146.148.64.0/18
- 130.211.4.0/22
3.6.3-meek-1, a stopgap security release until there is an alpha release.
mentioned in issue #11429 (moved)
mentioned in issue #11488 (moved)
mentioned in issue #15138 (moved)
mentioned in issue tpo/anti-censorship/pluggable-transports/meek#11488 (closed)
