meek issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues2020-06-27T13:44:22Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/10935Make bundles featuring meek2020-06-27T13:44:22ZDavid Fifielddcf@torproject.orgMake bundles featuring meekLet's try out some bundles with [[doc/meek|meek]].Let's try out some bundles with [[doc/meek|meek]].David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/10984PHP relay for meek2020-06-27T13:44:22ZArlo BreaultPHP relay for meekA first pass at the php middle relay is at,
https://github.com/arlolra/meek/tree/php
It borrows heavily from GoAgent.
Deployed to,
https://meek-reflect.herokuapp.com/A first pass at the php middle relay is at,
https://github.com/arlolra/meek/tree/php
It borrows heavily from GoAgent.
Deployed to,
https://meek-reflect.herokuapp.com/David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11183Make an HTTP requestor Firefox extension for meek-client2020-06-27T13:44:22ZDavid Fifielddcf@torproject.orgMake an HTTP requestor Firefox extension for meek-clientFollowing the discussion at https://lists.torproject.org/pipermail/tor-dev/2014-February/006266.html and the summary at [[doc/meek#HowtolooklikebrowserHTTPS]], I think our best option for having TLS that looks like a browser is to make a...Following the discussion at https://lists.torproject.org/pipermail/tor-dev/2014-February/006266.html and the summary at [[doc/meek#HowtolooklikebrowserHTTPS]], I think our best option for having TLS that looks like a browser is to make a browser extension that meek-client uses as a tool to make HTTPS requests.
To summarize: meek-client needs to make HTTPS requests, but needs to do so with a TLS signature that isn't trivially blockable. A browser doesn't have a blockable TLS signature, so we can have meek-client drive a browser to make requests on its behalf. Rather than ship an entire separate browser to users, we can use an extension in Tor Browser itself, one whose only purpose is to make HTTPS requests using the browser's networking code, bypassing the browser's proxy settings that would otherwise send all requests through Tor.
The communication goes:
browser ↔ tor ↔ meek-client ↔ extension ↔ www.google.com
There will need to be some kind of IPC between meek-client and the extension. I haven't figured out how that will work. Maybe the extension can be an HTTP proxy--that would be super easy to integrate with meek-client. But maybe you don't want an HTTP proxy running in your browser bundle, even if it's only intended for a specific purpose. Maybe the IPC needs to be authenticated somehow, and the extension needs to somehow inform the other process of how to contact it.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11393Make an HTTP requestor Chrome extension for meek-client2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgMake an HTTP requestor Chrome extension for meek-clientLike in legacy/trac#11183, make an extension for Chrome/Chromium that makes HTTP requests on behalf of another program.Like in legacy/trac#11183, make an extension for Chrome/Chromium that makes HTTP requests on behalf of another program.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11413meek README should say what meek is.2020-06-27T13:44:21ZNick Mathewsonmeek README should say what meek is.By convention, a project's README file should tell you what it is, what it does, and how to get started with it. Meek's only mentions that it's public domain.By convention, a project's README file should tell you what it is, what it does, and how to get started with it. Meek's only mentions that it's public domain.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11429meek-http-helper opens up a second dock icon2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgmeek-http-helper opens up a second dock iconThe second copy of firefox that is started by meek-client-torbrowser brings up a second Tor Browser dock icon on OS X. Better if we can find a way to hide it.
Something similar happens on Windows, but it doesn't look as bad because the ...The second copy of firefox that is started by meek-client-torbrowser brings up a second Tor Browser dock icon on OS X. Better if we can find a way to hide it.
Something similar happens on Windows, but it doesn't look as bad because the icons appear in a little stack.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11488Add meek to tor launcher2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgAdd meek to tor launcherCurrent bundles (3.5.4-meek-1, legacy/trac#10935) have meek turned on by default (with a Bridge line in torrc-defaults). For merging, we should rather add it to the bridge configuration screen in tor launcher.Current bundles (3.5.4-meek-1, legacy/trac#10935) have meek turned on by default (with a Bridge line in torrc-defaults). For merging, we should rather add it to the bridge configuration screen in tor launcher.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11504Time out requests in meek-server2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgTime out requests in meek-serverYawning found that the HTTP server in meek-server doesn't time out requests in progress.Yawning found that the HTTP server in meek-server doesn't time out requests in progress.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11562meek browser stops working after many idle hours2021-10-29T17:55:46ZDavid Fifielddcf@torproject.orgmeek browser stops working after many idle hoursI left a copy of [3.5.4-meek-1](https://lists.torproject.org/pipermail/tor-dev/2014-April/006718.html) running idle for a few days. When I came back and tried to browse somewhere, the browser said "connection timed out." I will attach lo...I left a copy of [3.5.4-meek-1](https://lists.torproject.org/pipermail/tor-dev/2014-April/006718.html) running idle for a few days. When I came back and tried to browse somewhere, the browser said "connection timed out." I will attach log files in a comment. Sending a HUP to tor caused it to reload its configuration but didn't help things. Neither did "New Identity." Closing the browser and starting it again worked.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11580Make meek man pages2020-06-27T13:44:21ZDavid Fifielddcf@torproject.orgMake meek man pagesFor:
* meek-client
* meek-server
Maybe also (only used in the bundle):
* meek-client-torbrowser
* terminateprocess-buffer
Join us for our next exciting episode, _Make `man meek` manifest meek manual_, or, _Three billy goats groff_.For:
* meek-client
* meek-server
Maybe also (only used in the bundle):
* meek-client-torbrowser
* terminateprocess-buffer
Join us for our next exciting episode, _Make `man meek` manifest meek manual_, or, _Three billy goats groff_.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/11612tbb bundle with meek takes (literally) hours to connect2020-06-27T13:44:21Zcypherpunkstbb bundle with meek takes (literally) hours to connectI tried out the experimental Tor Browser bundle with meek (version 3.5.4-meek-1-Linux, 32 bit).
When first launching the bundle, it took literally hours to make the first connection to the tor network. The progress bar was hung at ~50%, ...I tried out the experimental Tor Browser bundle with meek (version 3.5.4-meek-1-Linux, 32 bit).
When first launching the bundle, it took literally hours to make the first connection to the tor network. The progress bar was hung at ~50%, the console showed error messages like:
[notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 883/4458, and can only build 0% of likely paths. (We have 20% of guards bw, 21% of midpoint bw, and 21% of exit bw.)
[notice] Bootstrapped 72%: Loading relay descriptors.
[warn] Problem bootstrapping. Stuck at 72%: Loading relay descriptors. (DONE; DONE; count 1; recommendation warn)
I quit & restarted it several times, the bootstrapping progress seemed to restart from where it had left off, but it literally took hours before I had a tor browser window.
After that, TBB with meek worked reasonably well, albeit slower than normal Tor BrowserDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12120Enable Firefox meek-http-helper to use an upstream proxy2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgEnable Firefox meek-http-helper to use an upstream proxyThe helper should be able to use an upsteam proxy, so that it can be used to implement TOR_PT_PROXY as in legacy/trac#8402/[proposal 232](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/232-pluggable-transports-through-pro...The helper should be able to use an upsteam proxy, so that it can be used to implement TOR_PT_PROXY as in legacy/trac#8402/[proposal 232](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/232-pluggable-transports-through-proxy.txt).
[Commit cf81b598](https://gitweb.torproject.org/pluggable-transports/meek.git/commitdiff/cf81b598defd537ed65c015cbf79c322dad26b89) (the removed part) shows how to create a per-request proxy setting.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12146Firefox meek-http-helper leaks Host header in CONNECT requests2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgFirefox meek-http-helper leaks Host header in CONNECT requestslegacy/trac#12120 enabled the browser extension helper to use an upstream HTTP or SOCKS proxy. I'm watching the requests that go to the proxy, and Firefox is leaking the Host header in the proxy request:
```
CONNECT www.google.com:443 HT...legacy/trac#12120 enabled the browser extension helper to use an upstream HTTP or SOCKS proxy. I'm watching the requests that go to the proxy, and Firefox is leaking the Host header in the proxy request:
```
CONNECT www.google.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: meek-reflect.appspot.com
```
The `Host: meek-reflect.appspot.com` is not supposed to be visible on the wire. It's encrypted inside of HTTPS. But Firefox leaks it when configured to use an HTTP proxy.
The Host header must be getting special treatment, because the extension also sets X-Session-ID, and that's not showing up in the proxy request.
We have to turn off the HTTP proxy feature if we can't find a way to prevent the Host from leaking.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12208Make it possible to use an IP address as a front (no DNS request and no SNI)2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgMake it possible to use an IP address as a front (no DNS request and no SNI)meek puts one domain name on the "outside" of your connection (the DNS request and SNI), and a different name on the "inside" (the HTTP Host header). It would be good for some uses if the outside could be just to an IP address rather tha...meek puts one domain name on the "outside" of your connection (the DNS request and SNI), and a different name on the "inside" (the HTTP Host header). It would be good for some uses if the outside could be just to an IP address rather than a domain name, so that there were no DNS request, and no server_name extension in the CLientHello. Kind of like if you were to browse to https://38.229.72.16/ instead of https://www.torproject.org/.
The motivating use case is using a CDN as a front instead of www.google.com. A CDN has many domains behind it, but if we choose just one of them as the front, that domain might get blocked (because the collateral damage would be limited to just one domain). Such blocking would break the transport and also incidentally get the innocent third-party domain, who has nothing to do with any of this, censored even for non-circumventors. What we want is to use one of the CDN's frontend IP addresses as a front, so that the censor has to block the whole IP and the thousands of domains behind it, not just a single domain.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12402Meek bundle occasionally makes direct contact to Tor node.2020-06-27T13:44:20ZcypherpunksMeek bundle occasionally makes direct contact to Tor node.I have been testing with meek transport bundle 3.6.2.
I simply observed outbound connections with wireshark, and it was nearly always google's IP. But occasionally, it reaches out to a Tor node. In my case, it took 66 bytes from 5.135.59...I have been testing with meek transport bundle 3.6.2.
I simply observed outbound connections with wireshark, and it was nearly always google's IP. But occasionally, it reaches out to a Tor node. In my case, it took 66 bytes from 5.135.59.74 which is a Tor node (checked with ExoneraTOR)
I think this will let the traffic observer know you are connecting to tor network.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12428Make it possible to have multiple requests and responses in flight2023-03-21T21:26:20ZDavid Fifielddcf@torproject.orgMake it possible to have multiple requests and responses in flightmeek segments a data stream into multiple HTTP request–response pairs. In order to keep the segments in order, meek-client strictly serializes requests: it won't issue a second request until after it receives the response to its first re...meek segments a data stream into multiple HTTP request–response pairs. In order to keep the segments in order, meek-client strictly serializes requests: it won't issue a second request until after it receives the response to its first request, even if there is buffered data waiting to be sent.
The limit of one latent request–response is restricting possible throughput. For instance, if a user is located 200 ms from App Engine, and receives up to 64 KB per request, then their downstream throughput can be no greater than 64 KB/200 ms = 320 KB/s, even if everything after App Engine were instantaneous. Longer delays lead to even lower throughput.
The problem is how to deal with out-of-order arrivals, and retransmissions when an HTTP transaction fails. My plan is to add sequence numbers and acknowledgements to upstream and downstream HTTP headers, similar to what we did in OSS (https://www.bamsoftware.com/papers/oss.pdf section 4). The seq number is the index of the first byte of a payload in the overall stream. The ack number is the index of the next byte we're expecting from the other side. We can implement this idea in a backward-compatible way, by having the server guess in seq and ack fields when they are missing; old clients that serialize will continue to work.
There's a complication related to the protocol's polling nature. During a big download, we want multiple downstream responses to be in flight. In order to get that, we need to speculatively send a bunch of requests and see if they get responses that have data. My thinking is to do something like [TCP congestion avoidance](https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm), where we increment the number of speculative probes we send by 1 every time we get a response back with data. Maybe only when we get a full-sized response. Reset the number to 1 when there is a loss event.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12671Does meek's network-facing browser run javascript?2020-06-27T13:44:20ZRoger DingledineDoes meek's network-facing browser run javascript?Can Amazon S3 pass javascript to meek's network-facing browser (i.e. the copy of Tor Browser that it runs with a separate profile), and it will run it?
Seems like disabling javascript would provide a way for S3 to distinguish meek users...Can Amazon S3 pass javascript to meek's network-facing browser (i.e. the copy of Tor Browser that it runs with a separate profile), and it will run it?
Seems like disabling javascript would provide a way for S3 to distinguish meek users from the typical web user, but leaving it enabled would be sad (and surprising) for users who prefer to disable javascript. That said, there are already other ways for S3 itself to learn that it's a meek user, and there shouldn't be a way for an external observer to learn whether they run it? And in that case it would be wise to lock down meek's browser at least as much as tor browser itself?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12674Neuter meek-http-helper's default proxy setting2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgNeuter meek-http-helper's default proxy settingThe headless meek-http-helper browser undoes Tor Browser's proxy setting:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/5400da654020a34edb9edee70a0583a89231c4fe:/Bundle-Data/PTConfigs/meek-http-helper-user.js#l7
...The headless meek-http-helper browser undoes Tor Browser's proxy setting:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/5400da654020a34edb9edee70a0583a89231c4fe:/Bundle-Data/PTConfigs/meek-http-helper-user.js#l7
{{{
// 0 is "No proxy".
user_pref("network.proxy.type", 0);
}}}
This setting used to be necessary in order for the HTTPS requests to be made on the network without themselves trying to go through the local tor proxy. However, since legacy/trac#12120, we [set the proxy type individually for every request](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/firefox/components/main.js#l134) (including a "direct" non-proxy when TOR_PT_PROXY is unset), so it's no longer necessary to change the global setting.
A good reason to leave the proxy set is so if someone manages to start Firefox using the meek-http-helper profile as a normal non-headless browser, it should fail closed, and give "the proxy server is refusing connections" rather than acting as an unproxied browser.
Even better, we can set the proxy URL to 127.0.0.1:9, the discard port, so it will fail even closeder if tor happens to be running on the usual port set by Tor Browser.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12716Make meek-client-torbrowser take the firefox command as a parameter2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgMake meek-client-torbrowser take the firefox command as a parametermeek-client-torbrowser hardcodes the firefox binary and profile paths: [linux](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/linux.go) [mac](https://gitw...meek-client-torbrowser hardcodes the firefox binary and profile paths: [linux](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/linux.go) [mac](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/mac.go) [windows](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/2ef6e31de94eb10d40464a38909373114ff44132:/meek-client-torbrowser/windows.go). The problem is that when Tor Browser is reorganized, as it was in legacy/trac#11641, you need to make the corresponding change in meek-client-torbrowser, for example [178572f5](https://gitweb.torproject.org/pluggable-transports/meek.git/commitdiff/178572f5f1bb52200fa4c45497298241a745d8af).
meek-client-torbrowser already takes the full meek-client command on the command line; it [looks like](https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/a2370de2b0b44a22f3f2591c2960cd6767940b8b:/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix#l14):
```
ClientTransportPlugin meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.com
```
I don't know of a good clear way to encode two separate command lines into the command line of another program, except maybe to do them both as long strings and then parse the strings before calling exec.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12766Disable TLSv1.1 and TLSv1.2 in the Firefox helper2020-06-27T13:44:20ZDavid Fifielddcf@torproject.orgDisable TLSv1.1 and TLSv1.2 in the Firefox helperWith legacy/trac#11253, Tor Browser's Firefox config has TLSv1.1 and TLSv1.2 turned on. If meek-http-helper (browser TLS camouflage) sends Firefox 24 ciphersuites but uses TLSv1.1 or TLSv1.2, then it will look weird, because as I underst...With legacy/trac#11253, Tor Browser's Firefox config has TLSv1.1 and TLSv1.2 turned on. If meek-http-helper (browser TLS camouflage) sends Firefox 24 ciphersuites but uses TLSv1.1 or TLSv1.2, then it will look weird, because as I understand it, mainline Firefox 24 has TLSv1.1 and TLSv1.2 disabled. ([[doc/meek#Sampleclienthellos]] corroborates that ordinary Firefox 24 uses TLSv1.0 when connecting to Google.)
We also need to remember to turn TLSv1.1 and TLSv1.2 back on when they get enabled in the next ESR...David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12774"Firefox is already running" when you select meek after bootstrapping2021-11-08T19:49:21ZDavid Fifielddcf@torproject.org"Firefox is already running" when you select meek after bootstrapping1.Let Tor Browser bootstrap without any pluggable transports.
2. Open Network Settings and choose meek.
An alert appears:
Firefox is already running, but is not responding. To open a new window, you must first close the existing Fire...1.Let Tor Browser bootstrap without any pluggable transports.
2. Open Network Settings and choose meek.
An alert appears:
Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.
After that you can't browse. But closing the browser and allowing it to bootstrap from scratch again (with meek) works.
Tested on 3.6.3-meek-1 and on a build of the 4.0-alpha-1 branch.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12777Decide how to handle multiple meek backends in Tor Launcher2020-06-27T13:44:19ZDavid Fifielddcf@torproject.orgDecide how to handle multiple meek backends in Tor LauncherI made a [3.6.3-meek-2](https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/tags/tbb-3.6.3-meek-2) release that has a meek capable of using both [[doc/meek#GoogleAppEngine|Google App Engine]] and [[doc/meek#Amazon...I made a [3.6.3-meek-2](https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/tags/tbb-3.6.3-meek-2) release that has a meek capable of using both [[doc/meek#GoogleAppEngine|Google App Engine]] and [[doc/meek#AmazonCloudFront|Amazon CloudFront]] as backends.
* https://people.torproject.org/~dcf/pt-bundle/3.6.3-meek-2/
The idea behind having two (or more) is that one may work where another does not. The question is, how to usefully present the option? How is the user supposed to choose between them?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12778Put meek HTTP headers on a diet2020-06-27T13:44:19ZDavid Fifielddcf@torproject.orgPut meek HTTP headers on a dietLet's shorten the headers added by meek-client and meek-server where we can, to reduce the overhead of each request. I did some calculations recently and the overhead was greater than I expected, about 85% when the client sends a single ...Let's shorten the headers added by meek-client and meek-server where we can, to reduce the overhead of each request. I did some calculations recently and the overhead was greater than I expected, about 85% when the client sends a single Tor cell.
Here's a header sent by the Firefox meek-http-helper in the 3.6.2-meek-1 bundles, which use [meek 0.7](https://gitweb.torproject.org/pluggable-transports/meek.git/shortlog/refs/tags/0.7):
```
POST / HTTP/1.1\r\n
X-Session-Id: RAIzBBZBR5FFKxii7TBOldDAXUsBYI5+GhSKQPaQO6s=\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0\r\n
Host: meek-reflect.appspot.com\r\n
Content-Type: application/octet-stream\r\n
Content-Length: 543\r\n
Connection: keep-alive\r\n
Accept-Language: en-US,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
\r\n
```
It's 413 bytes (which can vary a bit depending on the Host and Content-Length headers). When it gets wrapped in its own TLS Application Data record, it adds about 50 bytes (the ciphersuite I get with Google is one that has to pad up to a block length).
(BTW I got the header by disabling the [headlessness](https://gitweb.torproject.org/pluggable-transports/meek.git/blob/refs/tags/0.7:/firefox/components/main.js#l76) of the browser extension, opening the browser console with Ctrl+Shift+J, and clicking on a request.)
A Tor cell is 514 bytes, and inside a TLS Application Data record it is 543 bytes. Therefore the overhead for sending one cell is (413+≈50)/543 ≈ 85%. Of course, the overhead is less when several cells are sent at once: ≈43% for two, and ≈28% for three.
Stuff set by meek-client that we could reduce:
* X-Session-Id: is 32 bytes (44 base64-encoded); could be 16 (24).
* Content-Type: is unnecessary, I think; remove it.
Stuff added by Firefox that we could reduce:
* User-Agent: could probably be removed.
* Accept-Language: could probably be removed.
* Accept-Encoding: could probably be removed.
* Accept: could probably be removed.
Stuff we should leave alone:
* Host
* Content-Length
* Connection
With meek-client changes we could save up to 60 bytes, and with meek-http-helper changes we could potentially save up to 217 bytes, leading to a header as small as 136 bytes, or an overhead of (136+≈50)/543 ≈ 34% when sending one Tor cell; ≈17% for two; and ≈11% for three.
We should also check what the server's response headers.
(NB not that I think HTTP header overhead is the main cause of perceived slowness; I'll bet [[ticket:12428|serialization of requests]] has a bigger effect.)
(What about SPDY? Does it have smaller headers? Yes, good thought. It is actually possible to use SPDY with the [[ticket:11393|Chrome extension]]. But Chromium doesn't allow you to override the Host header when you use SPDY ([Chromium #364319](https://code.google.com/p/chromium/issues/detail?id=364319)), so it doesn't work.)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12857Use streaming downloads2023-05-22T16:50:49ZDavid Fifielddcf@torproject.orgUse streaming downloadsHow meek works now is, the client reads a small chunk of data from tor (up to 64 KB) and sends it in the body of a POST request. The server receives it, reads a small chunk of data from tor (up to 64 KB), and sends it back in the respons...How meek works now is, the client reads a small chunk of data from tor (up to 64 KB) and sends it in the body of a POST request. The server receives it, reads a small chunk of data from tor (up to 64 KB), and sends it back in the response. The client doesn't make another request until it has received the response to the first one, in order to keep all the chunks of data in order.
Here's what would be better. The client sends a small chunk of data. The server sends a response header and any data it has pending, and leaves the response channel open. The server can use the chunked transfer-encoding to send a body of indeterminate length. The server sends downstream data over the existing streaming response channel until it receives another request. At that point, it closes the response channel and opens up a new one (which will be the response to the just-received request).
The advantages are mainly about performance: there's no client polling; there's less HTTP header overhead (see legacy/trac#12778); and the client can send data (send a request) whenever it feels like it, without waiting for the server's most recent response, if the underlying HTTP library supports pipelining.
Psiphon has already implemented something like this. There's a bit of difficulty in that the golang HTTP server [doesn't notify you of new requests while you're still sending a response on the same keep-alive channel](https://code.google.com/p/go/source/browse/src/pkg/net/http/server.go?r=238ff8c01b5b8749c5bffc00e1f6f5099359f1dd#1169). Their workaround (and I think it is a good one) is to put a timeout on the download streaming, so that a long response won't block upstream data forever.
* https://bitbucket.org/psiphon/psiphon-circumvention-system/diff/go/meek-server/meek-server.go?diff1=0ca24558e14e772a5b0e3dfb7b166914682a8fc0&diff2=692f9187147c&at=meek-performance
We'll need to overhaul the web browser extensions, because they currently assume requests and responses with sizes known in advance.
This approach won't work with Google App Engine, because App Engine [doesn't support streaming downloads](https://developers.google.com/appengine/docs/go/requests#Go_Responses). But it should work with CloudFront. See legacy/trac#12428 for how to improve performance with App Engine.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12873Reenable TLSv1.1 and TLSv1.2 in meek-http-helper when rebased on Firefox 31 ESR2020-06-27T13:44:19ZDavid Fifielddcf@torproject.orgReenable TLSv1.1 and TLSv1.2 in meek-http-helper when rebased on Firefox 31 ESRFirefox 31 has TLSv1.1 and TLSv1.2 enabled by default. We'll need to undo legacy/trac#12766 (just by removing the line that sets `security.tls.version.max=1`) in order to look like ordinary Firefox again. Making this a child of legacy/tr...Firefox 31 has TLSv1.1 and TLSv1.2 enabled by default. We'll need to undo legacy/trac#12766 (just by removing the line that sets `security.tls.version.max=1`) in order to look like ordinary Firefox again. Making this a child of legacy/trac#12620 so we're less likely to forget.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/12982Port Meek to Android2020-06-27T13:44:19ZcypherpunksPort Meek to AndroidMeek should be ported to Android, so it can be added to obfsclient of Orbot.
Meek makes more useful to run on handheld computers.Meek should be ported to Android, so it can be added to obfsclient of Orbot.
Meek makes more useful to run on handheld computers.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13160make a deb of meek and get into Debian2020-12-23T15:13:11Zpropermake a deb of meek and get into Debianaka
`apt-get install meek`
Speaking for Whonix, this would be very useful. Perhaps for Tails as well, but I am not speaking for them.aka
`apt-get install meek`
Speaking for Whonix, this would be very useful. Perhaps for Tails as well, but I am not speaking for them.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13171meek's reflector should forward the client's IP address/port to the bridge.2023-05-22T16:50:14ZYawning Angelmeek's reflector should forward the client's IP address/port to the bridge.It would be nice to do this so the value passed to the ExtORPort was correct for better metrics. A few ways this could be done, off the top of my head:
* Set `X-Forwarded-For`. The "standard" layout of this field doesn't include the p...It would be nice to do this so the value passed to the ExtORPort was correct for better metrics. A few ways this could be done, off the top of my head:
* Set `X-Forwarded-For`. The "standard" layout of this field doesn't include the port, but since it's unofficial, there's nothing stopping us from adding it. This would require us to secure the link between the reflector and the meek-server instance separately, which means TLS.
* Set a custom header (Eg: `Meek-Forwarded-For`), with a encrypted/encoded IP/Port pair. Less overhead than bringing TLS into the picture. I would use something like a Base64 encoded NaCl crypto_secretbox. Key management here may be an issue, though it depends on who runs the bridge and reflector (The other method has cert management to deal with so this isn't a strict minus IMO).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13174Amazon CloudFront sets X-Forwarded-For2020-06-27T13:44:18ZDavid Fifielddcf@torproject.orgAmazon CloudFront sets X-Forwarded-ForAmazon sets the X-Forwarded-For header that contains the client's true IP. Here's what the header looks like as it arrives at meek-server:
```
POST / HTTP/1.1
Host: d1727xplrgzao3.cloudfront.net
Via: 1.1 c54d7f08e2f3dab1918454910cc8aad0....Amazon sets the X-Forwarded-For header that contains the client's true IP. Here's what the header looks like as it arrives at meek-server:
```
POST / HTTP/1.1
Host: d1727xplrgzao3.cloudfront.net
Via: 1.1 c54d7f08e2f3dab1918454910cc8aad0.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4ygWFdM8S5fIh-pnW7BK7hKsA7vv6tba-G30YwVHLCXT2Kblcl_yDw==
Connection: Keep-Alive
Content-Length: 244
Accept-Encoding: gzip, deflate
X-Forwarded-Proto: https
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0
X-Forwarded-For: 192.0.2.101
CloudFront-Is-Mobile-Viewer: false
CloudFront-Is-Tablet-Viewer: false
CloudFront-Is-Desktop-Viewer: true
CloudFront-Viewer-Country: US
Accept-Language: en-US,en;q=0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
CloudFront-Forwarded-Proto: https
X-Session-Id: FHY4jxw72uodLxdRbrFtqRMnBbMxoa5USSuLj1pzh4w=
Content-Type: application/octet-stream
```
From a censorship point of view, the presence of the client IP address doesn't make a difference, because the request is out of the censor's view by the time the IP is visible. From a surveillance point of view, it doesn't really increase the exposure of clients over ordinary bridges or other transports, because someone surveilling one of those bridges also gets a list of client IPs. But if we can hide the IP on the link between the CDN and meek-server, then we can be in an even better situation with respect to surveillance.
Previously we didn't enable HTTPS on the link between App Engine and meek-server because it [comment:6:ticket:10935 increased latency]. That was for App Engine, though, not Amazon, and HTTPS is not as slow anymore with optimizations made in newer Go releases. (Now it's about 300 ms with HTTPS and 100 ms without.)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13182Meek's TLS client hello should use system time2020-06-27T13:44:18ZcypherpunksMeek's TLS client hello should use system timeSince Meek's purpose is to hide and blend in like a typical Firefox user browsing Google.com, the time sent in the TLS client hello handshake should use the user's local or system time, not the common time as in general tor usage.
This ...Since Meek's purpose is to hide and blend in like a typical Firefox user browsing Google.com, the time sent in the TLS client hello handshake should use the user's local or system time, not the common time as in general tor usage.
This will lead to meek page requests look like typical Google.com visit, to ISP, or anyone between user and ISP, or between ISP and Google App.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13189Set up an Azure backend2020-06-27T13:44:18ZDavid Fifielddcf@torproject.orgSet up an Azure backendI got a 12-month research pass for [[doc/meek#MicrosoftAzure]].I got a 12-month research pass for [[doc/meek#MicrosoftAzure]].David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13306meek should use the user's country Google site2020-06-27T13:44:18ZTracmeek should use the user's country Google siteAccording to the documentation, meek-google uses google.com as the front-end site.
However, google.com would redirect the browser to a local site - e.g. google.co.uk, google.ae, google.com.sa etc.
**Trac**:
**Username**: john1deerAccording to the documentation, meek-google uses google.com as the front-end site.
However, google.com would redirect the browser to a local site - e.g. google.co.uk, google.ae, google.com.sa etc.
**Trac**:
**Username**: john1deerDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13335Guide on how to use various public services for meek2020-06-27T13:44:18ZXimin LuoGuide on how to use various public services for meek<dcf1> You only need a reflector-like thing when the CDN-like thing doesn't let you point to arbitrary domains.
<dcf1> Amazon CloudFront lets you point to any domain, so the reflector is the CDN itself.
<dcf1> Google only lets you point ...<dcf1> You only need a reflector-like thing when the CDN-like thing doesn't let you point to arbitrary domains.
<dcf1> Amazon CloudFront lets you point to any domain, so the reflector is the CDN itself.
<dcf1> Google only lets you point to a Google domain, so to get around that you run an app on App Engine.
<dcf1> Azure also only allows you to point to an Azure domain, so you use the PHP or WSGI code.
It would be nice to collect this information into a document in meek.git for others.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/13442Check TLS fingerprint in Tor Browser 4.02022-07-25T22:20:04ZDavid Fifielddcf@torproject.orgCheck TLS fingerprint in Tor Browser 4.0Make sure we still only differ in client randomness as claimed at [[doc/meek#Sampleclienthellos]]. Also update that section of the wiki page.Make sure we still only differ in client randomness as claimed at [[doc/meek#Sampleclienthellos]]. Also update that section of the wiki page.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/14203Tor Browser with meek opens two Software Update windows2020-06-27T13:44:18ZDavid Fifielddcf@torproject.orgTor Browser with meek opens two Software Update windowsWhen I'm browsing with meek, I tend to get two "Software Update Available" windows appearing simultaneously. I suppose the second one is from the headless meek-http-helper.When I'm browsing with meek, I tend to get two "Software Update Available" windows appearing simultaneously. I suppose the second one is from the headless meek-http-helper.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/14256Clarify whether Cloudflare's Universal SSL thing works with meek2020-06-27T13:44:18ZcypherpunksClarify whether Cloudflare's Universal SSL thing works with meekThe [Meek wiki](https://trac.torproject.org/projects/tor/wiki/doc/meek) page has a section on CloudFlare as a possible CDN to use, but seems to have been written before CloudFlare rolled out their [Universal SSL](https://blog.cloudflare....The [Meek wiki](https://trac.torproject.org/projects/tor/wiki/doc/meek) page has a section on CloudFlare as a possible CDN to use, but seems to have been written before CloudFlare rolled out their [Universal SSL](https://blog.cloudflare.com/introducing-universal-ssl/) free tier.
Would it be possible to have a meek-cloudflare using this Universal SSL thing?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/14897meek-client looks for /etc/resolv.conf on Android2020-06-27T13:44:17ZNathan Freitasmeek-client looks for /etc/resolv.conf on AndroidI have meek-client successfully cross compiled and starting up on Android, but as requests come in, there is a DNS lookup that relies on /etc/resolv.conf which doesn't exist on Android:
2015/02/13 16:16:00 error in handling request: dia...I have meek-client successfully cross compiled and starting up on Android, but as requests come in, there is a DNS lookup that relies on /etc/resolv.conf which doesn't exist on Android:
2015/02/13 16:16:00 error in handling request: dial tcp: error reading DNS config: open /etc/resolv.conf: no such file or directoryDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/15125meek-client-torbrowser does not use signals well2020-06-27T13:44:17ZXimin Luomeek-client-torbrowser does not use signals wellWhen testing meek-client-wrapper, I noticed two things:
- it does not respond to SIGINT or SIGKILL. also, the signal handling code is different from meek-client. perhaps we should move it to goptlib?
- it uses sigkill to kill its childr...When testing meek-client-wrapper, I noticed two things:
- it does not respond to SIGINT or SIGKILL. also, the signal handling code is different from meek-client. perhaps we should move it to goptlib?
- it uses sigkill to kill its children, not giving them a chance to clean up. Yes, this is awkward on windows but we can at least do something nicer on posix systems.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/15158meek-client should support SOCKS proxies w/o Firefox2020-06-27T13:44:17ZNathan Freitasmeek-client should support SOCKS proxies w/o FirefoxWith meek on Android 4.x in Orbot's VPN mode, we need to proxy outbound connections through a loopback proxy in order to flag socket connections to not go through the VPN. Currently, we have a local SOCKS proxy that does this for tor and...With meek on Android 4.x in Orbot's VPN mode, we need to proxy outbound connections through a loopback proxy in order to flag socket connections to not go through the VPN. Currently, we have a local SOCKS proxy that does this for tor and obfs4, but since meek requires Firefox to use SOCKS we can't support it in VPN mode.
It would be great to have meek supports SOCKS natively w/o needing Firefox.
We currently use SOCKS 5, but can support SOCKS 4 as well, via this java class:
https://github.com/guardianproject/OrbotVPN/blob/master/src/com/runjva/sourceforge/jsocks/protocol/ProxyServer.javaYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/15427Firefox helper broken when front= is missing2020-06-27T13:44:17ZDavid Fifielddcf@torproject.orgFirefox helper broken when front= is missing[0e6ced86](https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=0e6ced86880b54f57a80b34d7f1b32a0eaa33b48) (legacy/trac#12778) broke the Firefox helper when the bridge line is missing the "front" parameter, because it st...[0e6ced86](https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=0e6ced86880b54f57a80b34d7f1b32a0eaa33b48) (legacy/trac#12778) broke the Firefox helper when the bridge line is missing the "front" parameter, because it strips off the Host header and doesn't put it back.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/15512Check meek TLS fingerprint on ESR 382022-07-25T22:20:04ZDavid Fifielddcf@torproject.orgCheck meek TLS fingerprint on ESR 38legacy/trac#15196 Rebase Tor Browser patches to ESR 38
See legacy/trac#13442 for an earlier version of this ticket on ESR 31.legacy/trac#15196 Rebase Tor Browser patches to ESR 38
See legacy/trac#13442 for an earlier version of this ticket on ESR 31.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/15523Meek with google is much slower in TBB 4.0.5 than in TBB 4.0.32020-06-27T13:44:17ZcypherpunksMeek with google is much slower in TBB 4.0.5 than in TBB 4.0.3Using Meek - Google in TBB 4.0.5 is much slower than normal tor speed received in TBB 4.0.3 with Meek - Google.So I had gone back to 4.0.3 until this is fixed.
I know speed of internet is not a simple problem, but I have tested this agai...Using Meek - Google in TBB 4.0.5 is much slower than normal tor speed received in TBB 4.0.3 with Meek - Google.So I had gone back to 4.0.3 until this is fixed.
I know speed of internet is not a simple problem, but I have tested this again and again, no effect. 4.0.5 meek-google is much slow and unusable while meek-google in 4.0.3 is at normal expected tor speed.
I guess this sounds like bad report without extra info, but if you tell how, I can give more info on it.
I have not tested with TBB 4.0.4.
I posted above as comment in a blog post, but I reposted here to bring it to attention of good meek developers, apology! Thanks.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/16269add-on compatibility check occurs repeatedly2020-06-27T13:44:16ZMark Smithadd-on compatibility check occurs repeatedlyThis is a spinoff of ticket legacy/trac#16014. Georg noticed that after he updated Tor Browser 4.5a5 to 5.0a1, he saw a "Checking Compatibility of Add-ons" window each time he started the browser. Kathy and I debugged this and found th...This is a spinoff of ticket legacy/trac#16014. Georg noticed that after he updated Tor Browser 4.5a5 to 5.0a1, he saw a "Checking Compatibility of Add-ons" window each time he started the browser. Kathy and I debugged this and found that this window is coming from the meek helper browser. It shows up repeatedly because the prefs.js file is not being written to the profile (presumably because the meek browser is killed and does not exit in a clean manner).
One way to fix this is to add code to the meek HTTP helper extension that flushes the browser prefs. to disk before it enters the blocking event loop. There may be a better solution, but this seems to solve the problem.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/16498Update meek quick start screenshots for TB 4.52020-06-27T13:44:16ZDavid Fifielddcf@torproject.orgUpdate meek quick start screenshots for TB 4.5[[doc/meek#Quickstart]]
The order of dialogs has changed. I manually rearranged the TB 4.0 screenshots, but that means "Connect" is on the wrong screen.[[doc/meek#Quickstart]]
The order of dialogs has changed. I manually rearranged the TB 4.0 screenshots, but that means "Connect" is on the wrong screen.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/17890Separate the meek bridge backing paid CDNs from the one we tell the general p...2020-06-27T13:44:16ZDavid Fifielddcf@torproject.orgSeparate the meek bridge backing paid CDNs from the one we tell the general public to useIn source code and examples, we recommend !https://meek.bamsoftware.com/ (port 443) for use by the general public. But that's also the backing bridge for meek-azure, and it's rate-limited to reduce costs.
We should split it into two bri...In source code and examples, we recommend !https://meek.bamsoftware.com/ (port 443) for use by the general public. But that's also the backing bridge for meek-azure, and it's rate-limited to reduce costs.
We should split it into two bridges (e.g. running on different ports). Rate-limit the one behind the paid CDN, because that's the expensive one. Make the other one unlimited (if someone else is paying the CDN fees, they can use all the bandwidth they want).
This will enable more people to use the default meek-azure at the same speed, while enabling people who set up their own to go fast.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/18077meek-server logging client IP addresses in some situations2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgmeek-server logging client IP addresses in some situationsToday a meek-server operator saw new types of error, the text of which includes client IP addresses:
```
http: TLS handshake error from X.X.X.X:YYYY: EOF
http: TLS handshake error from X.X.X.X:YYYY: read tcp X.X.X.X:YYYY: i/o timeout
```Today a meek-server operator saw new types of error, the text of which includes client IP addresses:
```
http: TLS handshake error from X.X.X.X:YYYY: EOF
http: TLS handshake error from X.X.X.X:YYYY: read tcp X.X.X.X:YYYY: i/o timeout
```David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/18141Tame "reading from ORPort" error logs in meek-server2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgTame "reading from ORPort" error logs in meek-servermeek-server operators have asked to disable this error message:
```
reading from ORPort: read tcp 127.0.0.1:YYYY->127.0.0.1:ZZZZ: read: connection reset by peer
```
It occurs whenever tor closes the TCP connection between meek-server an...meek-server operators have asked to disable this error message:
```
reading from ORPort: read tcp 127.0.0.1:YYYY->127.0.0.1:ZZZZ: read: connection reset by peer
```
It occurs whenever tor closes the TCP connection between meek-server and itself. This happens very frequently when you restart the meek-server process, because it loses its cache of current session-IDs. When clients connect using their formerly valid session-IDs, meek-server treats them as new connections and opens new ORPort connections. The clients push TLS application data over the new connection, which doesn't match what tor expects from a new connection, so it shuts it down. Right after restarting you get a ton of these messages for a while (can be more than 10 per second).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/18655Make meek-server easy to use with Let's Encrypt2020-06-27T13:44:16ZDavid Fifielddcf@torproject.orgMake meek-server easy to use with Let's EncryptCurrently it's not trivial to get certificates for meek-server using Let's Encrypt. The `--webroot` option, for example, wants to write a token to the filesystem so the web server can serve it, but meek-server doesn't serve files from th...Currently it's not trivial to get certificates for meek-server using Let's Encrypt. The `--webroot` option, for example, wants to write a token to the filesystem so the web server can serve it, but meek-server doesn't serve files from the filesystem.
Ideally this works in a way that certificates can be renewed (e.g. in a cron job) without restarting tor or meek-server.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/18904Mac OS: meek-http-helper profile not updated2020-06-27T13:44:16ZMark SmithMac OS: meek-http-helper profile not updatedAfter the changes from legacy/trac#13252 and related tickets were merged, on Mac OS a template is used to create the meek-http-helper browser profile. Unfortunately, the meek-client-torbrowser code that Kathy and I wrote to copy files do...After the changes from legacy/trac#13252 and related tickets were merged, on Mac OS a template is used to create the meek-http-helper browser profile. Unfortunately, the meek-client-torbrowser code that Kathy and I wrote to copy files does not account for the fact that files within the template may change during a Tor Browser update (it only copies files if the profile.meek-http-helper directory does not exist).Mark SmithMark Smithhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/18927Check meek fingerprint on ESR 452022-07-25T22:20:05ZDavid Fifielddcf@torproject.orgCheck meek fingerprint on ESR 45legacy/trac#15197
Previous tickets like this are legacy/trac#15512 and legacy/trac#13442.legacy/trac#15197
Previous tickets like this are legacy/trac#15512 and legacy/trac#13442.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/19426meek-client on ubuntu requires apparmor profile adjustment for system_tor2021-11-08T19:49:21ZTracmeek-client on ubuntu requires apparmor profile adjustment for system_tormeek-client
$ apt-cache policy tor
tor:
Installed: 0.2.7.6-1ubuntu1
$ apt-cache policy meek-client
meek-client:
Installed: 0.20+git20151006-1
Candidate: 0.20+git20151006-1
Version table:
*** 0.20+git20151006-1 500
500 ...meek-client
$ apt-cache policy tor
tor:
Installed: 0.2.7.6-1ubuntu1
$ apt-cache policy meek-client
meek-client:
Installed: 0.20+git20151006-1
Candidate: 0.20+git20151006-1
Version table:
*** 0.20+git20151006-1 500
500 https://people.debian.org/~infinity0/apt unstable/contrib amd64 Packages
$ dmesg | tail -n 1
[ 2553.433359] audit: type=1400 audit(1466045658.589:84): apparmor="DENIED" operation="open" profile="system_tor" name="/proc/sys/net/core/somaxconn" pid=7983 comm="meek-client" requested_mask="r" denied_mask="r" fsuid=117 ouid=0
You need to add the following to your config at /etc/apparmor.d/system_tor:
/proc/sys/net/core/somaxconn r,
This allows meek-client to read the procfs setting when called by tor.
**Trac**:
**Username**: 6h72Q484AddGha8HDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/19646Mac OS: wrong location for meek browser profile2020-06-27T13:44:15ZMark SmithMac OS: wrong location for meek browser profileWith Tor Browser 6.0 and newer, Meek is not working at all for some Mac OS users. Anonymous said on https://blog.torproject.org/blog/tor-browser-60-released:
Note to all OSX users encountering similar error: make sure before upgrade/cle...With Tor Browser 6.0 and newer, Meek is not working at all for some Mac OS users. Anonymous said on https://blog.torproject.org/blog/tor-browser-60-released:
Note to all OSX users encountering similar error: make sure before upgrade/clean install for 6.0+ that user installing has sudo privileges. TorBrowser needs write access to /Applications/TorBrowser-Data/ which will fail unless the user is an administrator. sudo privileges can be removed after installation and first run without problems.
Kathy and I were able to reproduce this problem on Mac OS 10.11.5 using a clean install of Tor Browser 6.0 (placed in /Applications) when logged in as a non-admin user.
The problem is that the meek-client-torbrowser code that creates the Meek browser profile does not account for the fact that the user data should be stored under ~/Library/Application Support/TorBrowser-Data when the browser is in /Applications. In fact, Meek works correctly when running as a privileged (admin) user, but the Meek helper profile is incorrectly placed under /Applications/TorBrowser-Data/ (the main browser profile is correctly placed under ~/Library/Application Support/TorBrowser-Data).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/20030meek-http-helper doesn't shutdown cleanly in 6.5a12020-06-27T13:44:15ZArlo Breaultmeek-http-helper doesn't shutdown cleanly in 6.5a1I've got this process hanging around after I close TB 6.5a2,
```
/Applications/TorBrowser.app/Contents/MacOS/firefox --invisible -no-remote -profile /Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper
```
See...I've got this process hanging around after I close TB 6.5a2,
```
/Applications/TorBrowser.app/Contents/MacOS/firefox --invisible -no-remote -profile /Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper
```
Seems reproducible enough on this day.
Using meek-amazon. meek-azure no longer seems reachable.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/20250meek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.32020-06-27T13:44:15ZTracmeek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.3Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.
On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.
With 10.12,...Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.
On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.
With 10.12, (tested with admin and standard accounts), the initial tor connection UI completes, the browser opens and the initial meek connection is established. However, briefly after the browser window has opened with the successful about:tor page it is clear something is wrong. Monitoring internet traffic with a network monitor it is clear that the traffic to the meek server stops almost immediately after the browser has opened.
Having read some of the control port issues for other 10.12 users, I tested this issue with the extensions.torlauncher.control_port_use_socket pref set to false in prefs.js and without it, but it had no effect either way.
Attached are the tor, meek-client and meek-client-torbrowser logs. Really hope someone can help with this since meek is the only way to use tor in my country without having the police banging down the door.
Tor Log:
AUTHENTICATE <HASH>
250 OK
SETEVENTS STATUS_CLIENT NOTICE WARN ERR
250 OK
650 NOTICE Opening Socks listener on 127.0.0.1:9150
650 NOTICE Bootstrapped 5%: Connecting to directory server
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server"
650 NOTICE Bootstrapped 10%: Finishing handshake with directory server
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server"
650 NOTICE Bootstrapped 15%: Establishing an encrypted directory connection
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=15 TAG=onehop_create SUMMARY="Establishing an encrypted directory connection"
650 NOTICE Bootstrapped 20%: Asking for networkstatus consensus
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=20 TAG=requesting_status SUMMARY="Asking for networkstatus consensus"
650 NOTICE Bootstrapped 25%: Loading networkstatus consensus
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=25 TAG=loading_status SUMMARY="Loading networkstatus consensus"
650 STATUS_CLIENT NOTICE CONSENSUS_ARRIVED
650 STATUS_CLIENT NOTICE ENOUGH_DIR_INFO
650 NOTICE Bootstrapped 80%: Connecting to the Tor network
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=80 TAG=conn_or SUMMARY="Connecting to the Tor network"
650 NOTICE Bootstrapped 90%: Establishing a Tor circuit
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=90 TAG=circuit_create SUMMARY="Establishing a Tor circuit"
650 NOTICE Tor has successfully opened a circuit. Looks like client functionality is working.
650 NOTICE Bootstrapped 100%: Done
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"
650 STATUS_CLIENT NOTICE CIRCUIT_ESTABLISHED
650 NOTICE New control connection opened from 127.0.0.1.
650 NOTICE New control connection opened from 127.0.0.1.
#NOTICE THE LINE BELOW:
650 WARN The connection to the SOCKS4 proxy server at 127.0.0.1:57343 just failed. Make sure that the proxy server is up and running.
650 NOTICE Delaying directory fetches: No running bridges
650 NOTICE Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)
meek-client log:
0:05 using helper on 127.0.0.1:49193
0:05 listening on 127.0.0.1:49196
0:33 using helper on 127.0.0.1:49199
0:33 listening on 127.0.0.1:49202
meek-client-torbrowser log:
0:00 running firefox command ["/Applications/TorBrowser.app/Contents/MacOS/firefox" "--invisible" "-no-remote" "-profile" "/Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper"]
0:00 firefox started with pid 3644
0:01 running meek-client command ["PluggableTransports/meek-client" "--log" "meek-client.txt" "--helper" "127.0.0.1:49193"]
0:01 meek-client started with pid 3646
0:27 sig terminated
0:27 sending signal terminated to PID 3646
0:27 killing PID 3646
0:27 killing PID 3644
0:32 running firefox command ["/Applications/TorBrowser.app/Contents/MacOS/firefox" "--invisible" "-no-remote" "-profile" "/Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper"]
0:32 firefox started with pid 3660
0:33 running meek-client command ["PluggableTransports/meek-client" "--log" "meek-client.txt" "--helper" "127.0.0.1:49199"]
0:33 meek-client started with pid 3661
1:00 sig terminated
1:00 sending signal terminated to PID 3661
1:00 killing PID 3661
1:00 killing PID 3660
**Trac**:
**Username**: tordevSZ0David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/20451The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'2020-06-27T13:44:15ZTracThe communication stream of managed proxy '/usr/bin/meek-client' is 'closed'Tested on archlinux, using this package https://aur.archlinux.org/packages/meek/. PKGBUILD seems ok, meek-client is working (tested with `meek-client --help`)
torrc file:
```
Log notice syslog
DataDirectory /var/lib/tor
UseBridges 1
Clie...Tested on archlinux, using this package https://aur.archlinux.org/packages/meek/. PKGBUILD seems ok, meek-client is working (tested with `meek-client --help`)
torrc file:
```
Log notice syslog
DataDirectory /var/lib/tor
UseBridges 1
ClientTransportPlugin meek exec /usr/bin/meek-client --log meek-client.log
Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.com
Bridge meek 0.0.2.0:2 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com
```
Tor service status:
```
● tor.service - Anonymizing Overlay Network
Loaded: loaded (/usr/lib/systemd/system/tor.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Oct 25 05:20:07 laptop Tor[26070]: Delaying directory fetches: No running bridges
Oct 25 05:20:08 laptop Tor[26070]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors.
Oct 25 05:20:09 laptop Tor[26070]: Bootstrapped 5%: Connecting to directory server
Oct 25 05:20:09 laptop Tor[26070]: We were supposed to connect to bridge '0.0.2.0:3' using pluggable transport 'meek', but we can't find a pluggable transport proxy supporting 'meek'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
Oct 25 05:20:09 laptop Tor[26070]: Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.2.0:3)
Oct 25 05:20:09 laptop Tor[26070]: We were supposed to connect to bridge '0.0.2.0:2' using pluggable transport 'meek', but we can't find a pluggable transport proxy supporting 'meek'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
Oct 25 05:20:09 laptop Tor[26070]: Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 2; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.2.0:2)
Oct 25 05:21:31 laptop systemd[1]: Stopping Anonymizing Overlay Network...
Oct 25 05:21:31 laptop Tor[26070]: Interrupt: exiting cleanly.
Oct 25 05:21:31 laptop systemd[1]: Stopped Anonymizing Overlay Network.
```
Meek doesn't create any log files.
**Trac**:
**Username**: tagener-noisuDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/20600meek-client-torbrowser should always use TOR_BROWSER_TOR_DATA_DIR2021-11-08T19:49:21ZMark Smithmeek-client-torbrowser should always use TOR_BROWSER_TOR_DATA_DIRCurrently, we only use the TOR_BROWSER_TOR_DATA_DIR env var on OSX. When we move user data out of the Browser directory on Linux and Windows, we should clean up the meek-client-torbrowser code so that the meek browser profile path is alw...Currently, we only use the TOR_BROWSER_TOR_DATA_DIR env var on OSX. When we move user data out of the Browser directory on Linux and Windows, we should clean up the meek-client-torbrowser code so that the meek browser profile path is always constructed using the env var. See ticket:19646#comment:15 for more background.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/21257meek-azure broken2020-06-27T13:44:15Zcypherpunksmeek-azure brokenmeek is the only option in my threat model. Noticed that azure server almost always fails to connect (tested in multiple countries). Amazon works fine. Maybe someone in torproject could test and if an error confirmed, check the status of...meek is the only option in my threat model. Noticed that azure server almost always fails to connect (tested in multiple countries). Amazon works fine. Maybe someone in torproject could test and if an error confirmed, check the status of the meek-azure server?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/21258meek PT stops functioning after long uptime2020-06-27T13:44:15Zcypherpunksmeek PT stops functioning after long uptimeRunning TorBrowser on macOS with meek PT fails after long uptime.
Scenarios:
1) Run machine for a day or more, then try to open torbrowser and connect, and it fails.
2) Boot machine, use torbrowser successfully for a period, quit a...Running TorBrowser on macOS with meek PT fails after long uptime.
Scenarios:
1) Run machine for a day or more, then try to open torbrowser and connect, and it fails.
2) Boot machine, use torbrowser successfully for a period, quit and then leave machine running for an extended period (a day at least) and then try to reopen torbrowser and connect -> fails to connect.
Interestingly, and for unknown reasons, adding the log options to meek-client and meek-client-torbrowser in torrc avoids this bug. Any thoughts?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/21836meek-azure seems broken2020-06-27T13:44:15Zcypherpunksmeek-azure seems brokenI am in a country where meek is the only thing that works. Amazon is much less stable than Azure for me normally, so thank you very much for keeping Azure alive - it is the only way to stay vaguely safe anymore.
I was using Azure with ...I am in a country where meek is the only thing that works. Amazon is much less stable than Azure for me normally, so thank you very much for keeping Azure alive - it is the only way to stay vaguely safe anymore.
I was using Azure with no issues on TorBrowser v6.5.1 an hour or so before this event. Then, some time after Mar 29 2017 2230UTC I tried to reconnect and the connection failed on the SSL handshake. I examined the traffic pattern using a traffic visualizer during the connection and all that occurred was a single pulse and then the connection died.
Nothing had been changed on my system - no updates, or firewall changes or anything else significant. To be sure, I tested on another machine which had not been used that day, but that had worked last time I used it a day earlier. Like the other machine, it also had a similar rapid connection failure. I am almost certain this is not an issue linked to my local machines and either is linked to the underlying bridge, something Microsoft has changed or something local authorities have done to break the Azure server. However, if it is caused by local authorities, I am a little unsure why only Azure would be broken.
Amazon, as I said, sort of works here, but can be very unstable and almost unusably slow as it is for me right now. If someone could just check to see if anything has happened to the Azure server, it would be greatly appreciated!
LOG SAMPLE:
Opening Socks listener on 127.0.0.1:9150
[NOTICE] Bootstrapped 5%: Connecting to directory server
[NOTICE] Bootstrapped 10%: Finishing handshake with directory server
[WARN] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 1; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CE at 0.0.2.0:3)
[WARN] 1 connections have failed:
[WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
[NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Closing old Socks listener on 127.0.0.1:9150
[NOTICE] Delaying directory fetches: DisableNetwork is set.
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
[NOTICE] Opening Socks listener on 127.0.0.1:9150
[NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection
[NOTICE] Bootstrapped 20%: Asking for networkstatus consensus
[NOTICE] new bridge descriptor 'TorLandMeek' (fresh): $B9E7141C594AF25699E0079C1F0146F409495296~TorLandMeek at 0.0.2.0https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/22515Check meek TLS fingerprint on ESR 522022-07-25T22:20:05ZDavid Fifielddcf@torproject.orgCheck meek TLS fingerprint on ESR 52legacy/trac#18927 previous ticket for ESR 45.legacy/trac#18927 previous ticket for ESR 45.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/22865Explicitly set Content-Length to zero when there is no data to send2020-06-27T13:44:14ZtwimExplicitly set Content-Length to zero when there is no data to sendSince Go 1.8 http.Transport does not set Content-Length header if body contains no bytes.
https://golang.org/doc/go1.8#net_http
https://go-review.googlesource.com/c/31445/
However some of domain fronts do inspect Content-Length header a...Since Go 1.8 http.Transport does not set Content-Length header if body contains no bytes.
https://golang.org/doc/go1.8#net_http
https://go-review.googlesource.com/c/31445/
However some of domain fronts do inspect Content-Length header and return 411 error when it is not set. This breaks connection entierly since these packets do not travel beyond a frontend to a meek server.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/24284meek-amazon does not work2020-06-27T13:44:14Zcypherpunksmeek-amazon does not workDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/24306Add some volunteer's public meek URLs to TBB, and also write a blog for meek.2020-06-27T13:44:14ZcypherpunksAdd some volunteer's public meek URLs to TBB, and also write a blog for meek.I'm hosting a meek service(coded in PHP, 1 file) for some people.I'm hosting a meek service(coded in PHP, 1 file) for some people.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/24640improve meek behavior when target server is down2023-08-01T19:36:47ZKathleen Bradeimprove meek behavior when target server is downAs part of our testing of Tor Launcher / Moat functionality, Mark and I ran our own meek-server but intentionally stopped the BridgeDB/moat server to which it was supposed to talk. This caused a 5 minute hang within Tor Launcher before ...As part of our testing of Tor Launcher / Moat functionality, Mark and I ran our own meek-server but intentionally stopped the BridgeDB/moat server to which it was supposed to talk. This caused a 5 minute hang within Tor Launcher before an error was generated.
On the meek-client side, we see a series of messages like these:
status code was 500, not 200; trying again after 30 seconds (9)
On the meek-server side, we see these messages:
dial tcp 192.168.1.xx:6790: getsockopt: connection refused
Because this is part of the Moat client implementation inside Tor Launcher, if BridgeDB is down a real person will be waiting a long time without receiving any feedback. It does not look like the retry interval or count is configurable within meek-client.
Do you have any suggestions for minimizing or eliminating the 5 minutes? We could implement a different maximum timeout inside Tor Launcher, although knowing that the underlying error is "connection refused" vs. "the network is just really slow" would make things more robust.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/24642cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser2020-06-27T13:44:14ZMark Smithcannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowserI am using meek built from the 0.28 tag on macOS.
If I add TOR_PT_EXIT_ON_STDIN_CLOSE=1 to the environment and start meek-client-torbrowser, the meek-client process that is started exits immediately. It generates this message on its way...I am using meek built from the 0.28 tag on macOS.
If I add TOR_PT_EXIT_ON_STDIN_CLOSE=1 to the environment and start meek-client-torbrowser, the meek-client process that is started exits immediately. It generates this message on its way out:
synthesizing SIGTERM because of stdin close
I think this happens because meek-client-torbrowser does not attach stdin to anything when starting meek-client.
I am not sure how best to fix this. One approach would be for meek-client-torbrowser to remove TOR_PT_EXIT_ON_STDIN_CLOSE=1 from the environmnt before starting meek-client (since meek-client-torbrowser already handles TOR_PT_EXIT_ON_STDIN_CLOSE=1 on its own).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/24875meek-client doesn't exit on close of stdin if there are no active handlers ru...2020-06-27T13:44:14ZDavid Fifielddcf@torproject.orgmeek-client doesn't exit on close of stdin if there are no active handlers runningIf you give meek-client an EOF while it's not currently handling any connections, it says it is terminating but doesn't quite terminate.
```
$ TOR_PT_EXIT_ON_STDIN_CLOSE=1 TOR_PT_MANAGED_TRANSPORT_VER=1 TOR_PT_CLIENT_TRANSPORTS=meek ./me...If you give meek-client an EOF while it's not currently handling any connections, it says it is terminating but doesn't quite terminate.
```
$ TOR_PT_EXIT_ON_STDIN_CLOSE=1 TOR_PT_MANAGED_TRANSPORT_VER=1 TOR_PT_CLIENT_TRANSPORTS=meek ./meek-client < /dev/null
VERSION 1
CMETHOD meek socks5 127.0.0.1:35831
2018/01/11 22:03:23 listening on 127.0.0.1:35831
CMETHODS DONE
2018/01/11 22:03:23 synthesizing SIGTERM because of stdin close
2018/01/11 22:03:23 got signal terminated
2018/01/11 22:03:23 error in AcceptSocks: accept tcp 127.0.0.1:35831: use of closed network connection
```
It's stuck in this loop, because it only checks `numHandlers == 0` inside the loop and not before entering.
```
for n := range handlerChan {
numHandlers += n
if numHandlers == 0 {
break
}
}
```David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/24928Use `Manager.HTTPHandler` (ACME "HTTP-01" challenge) for automatic certificates2024-01-07T23:57:57ZDavid Fifielddcf@torproject.orgUse `Manager.HTTPHandler` (ACME "HTTP-01" challenge) for automatic certificatesLet's Encrypt disabled the TLS-SNI challenge, which is the basis of the [autocert](https://godoc.org/golang.org/x/crypto/acme/autocert) package that meek-server uses for automatic TLS certificates:
* [tls-sni challenge disabled](https:/...Let's Encrypt disabled the TLS-SNI challenge, which is the basis of the [autocert](https://godoc.org/golang.org/x/crypto/acme/autocert) package that meek-server uses for automatic TLS certificates:
* [tls-sni challenge disabled](https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5a55777ed9a9c1024c00b241)
I've informed the public meek-server operators about this and asked that they be ready with manual certificates in the short term.
The autocert package recently added support for the HTTP-01 challenge. It requires the server to listen on port 80.
Further reading:
* [2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure](https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996)
* [2018.01.11 Update Regarding ACME TLS-SNI and Shared Hosting Infrastructure](https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188)
* [TLS-SNI challenges disabled for most new issuance](https://community.letsencrypt.org/t/tls-sni-challenges-disabled-for-most-new-issuance/50316)
* https://twitter.com/bradfitz/status/951909513593958400
> Use the #golang autocert package? You need to update your code due to @LetsEncrypt changes.
> You need to use this now: https://godoc.org/golang.org/x/crypto/acme/autocert#Manager.HTTPHandler
> See the example: https://godoc.org/golang.org/x/crypto/acme/autocert#example-Manager
> Everybody's sorry. Tears all around. 😢
* [x/crypto/acme/autocert: Support http-01 challenge (GitHub #21890)](https://github.com/golang/go/issues/21890)
* [acme/autocert: support http-01 challenge type](https://github.com/golang/crypto/commit/13931e22f9e72ea58bb73048bc752b48c6d4d4ac#diff-5738396ae12462da1c47c2f0f4bb8096)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/25613Close child's stdin to signal exit in meek-client-torbrowser2020-06-27T13:44:13ZDavid Fifielddcf@torproject.orgClose child's stdin to signal exit in meek-client-torbrowserMoved from legacy/trac#24642.
> Another (possibly better) option is to call `cmd.StdinPipe()` and just never close the pipe (that way the child process's stdin is separate from the parent's, so you don't have a race between them trying ...Moved from legacy/trac#24642.
> Another (possibly better) option is to call `cmd.StdinPipe()` and just never close the pipe (that way the child process's stdin is separate from the parent's, so you don't have a race between them trying to terminate when the stdin is closed).
> The [bug24642](https://gitweb.torproject.org/pluggable-transports/meek.git/log/?h=bug24642) branch uses the `StdinPipe` idea.
>
> I'm not totally happy with it, because ideally according to pt-spec, we should keep track of the stdin handle, and close it before sending anything like SIGTERM to the subprocess. But that would require more rewriting and is more than you need right now.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/25875Azure meek bridge bootstrap fails without meek-client-torbrowser proxy2020-06-27T13:44:13ZTracAzure meek bridge bootstrap fails without meek-client-torbrowser proxyI want to use tor(.exe) + meek bridge as a standalone application, without the Tor browser, but after changing the torrc to use the `meek-client` instead of `meek-client-torbrowser` the bootstrapping stucks at 85% when azure meek bridge ...I want to use tor(.exe) + meek bridge as a standalone application, without the Tor browser, but after changing the torrc to use the `meek-client` instead of `meek-client-torbrowser` the bootstrapping stucks at 85% when azure meek bridge selected. The `meek-client-torbrowser` executable fails to start without the Tor browser.
The amazon meek bridge bootstraps and works fine using the `meek-client` executable.
Operating system: Windows10 1703
Tor: 0.3.2.10
Tor Browser (and other binaries): 7.5.3 (latest) 32-bit
Added line to Browser\TorBrowser\Data\Tor\torrc:
`ClientTransportPlugin meek exec TorBrowser\Tor\PluggableTransports\meek-client`
Attaching the log file
**Trac**:
**Username**: habibDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/26103Can't use meek with any domain.2020-06-27T13:44:13ZTracCan't use meek with any domain.I have been using meek-client to connect to Tor, using Cloudfront.
I know Amazon has blocked domain fronting, but in my case, there is no need for domain fronting. I'm just using https://d2cly7j4zqgua7.cloudfront.net/ without fronting to...I have been using meek-client to connect to Tor, using Cloudfront.
I know Amazon has blocked domain fronting, but in my case, there is no need for domain fronting. I'm just using https://d2cly7j4zqgua7.cloudfront.net/ without fronting to connect, as *.cloudfront.net is whitelisted on the firewall. The problem is it just won't finish the handshake. I've even tried creating a cloudfront distribution myself, or hosting it on my own domain (on another network), and testing it but it just won't connect.
May 14 22:53:09.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 6; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.0.0:2)
May 14 22:53:09.000 [warn] 6 connections have failed:
May 14 22:53:09.000 [warn] 6 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
**Trac**:
**Username**: itslannasDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/26118Import Gecko Console without using shim2020-06-27T13:44:13ZMatthew FinkelImport Gecko Console without using shimIn Bug 1386535, Firefox 58, Mozilla deleted the devtools/shared/shim/ utils. Meek [[| imports](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/firefox/components/main.js#n43)] the shim (`re[/gre/modules/devtools/Console....In Bug 1386535, Firefox 58, Mozilla deleted the devtools/shared/shim/ utils. Meek [[| imports](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/firefox/components/main.js#n43)] the shim (`re[/gre/modules/devtools/Console.jsm`),](/gre/modules/devtools/Console.jsm`),) now it should use the new path `re[/gre/modules/Console.jsm`.](/gre/modules/Console.jsm`.)
https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Console.jsm was updated with this new path, too.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/26241Check meek TLS fingerprint on ESR 602022-07-25T22:20:06ZDavid Fifielddcf@torproject.orgCheck meek TLS fingerprint on ESR 60legacy/trac#22515 previous ticket for ESR 52.
https://lists.torproject.org/pipermail/tbb-dev/2018-May/000849.html
http://f4amtbsowhix7rrf.onion/tor-browser-builds/legacy/trac#22515 previous ticket for ESR 52.
https://lists.torproject.org/pipermail/tbb-dev/2018-May/000849.html
http://f4amtbsowhix7rrf.onion/tor-browser-builds/David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/26389Remove `handlerChan`, shut down immediately on SIGTERM2020-06-27T13:44:13ZcypherpunksRemove `handlerChan`, shut down immediately on SIGTERMDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/26891Problem running meek server without CDN, stuck at Performing bandwidth self-t...2023-08-01T19:36:47ZTracProblem running meek server without CDN, stuck at Performing bandwidth self-test...done**I am trying to run a meek server, and this is what I have done for the test:**
I have a domain (for example, call it example.com) and I manually applied for Let's Encrypt SSL certificate, so I can visit the website through https://exa...**I am trying to run a meek server, and this is what I have done for the test:**
I have a domain (for example, call it example.com) and I manually applied for Let's Encrypt SSL certificate, so I can visit the website through https://example.com.
**Here is the torrc:**
BridgeRelay 1
ORPort 9001
ExtORPort auto
SocksPort 0
ExitPolicy reject *:*
ServerTransportListenAddr meek 0.0.0.0:443
ServerTransportPlugin meek exec /usr/local/bin/meek-server --cert /etc/letsencrypt/live/example.com/fullchain.pem --key /etc/letsencrypt/live/example.com/privkey.pem --log /var/log/tor/meek-server.log
**However, when I enter "tor -f torrc", it stuck here:**
Jul 20 15:29:53.566 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2g, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.1.
Jul 20 15:29:53.567 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 20 15:29:53.567 [notice] Read configuration file "/xxx/torrc".
Jul 20 15:29:53.574 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Jul 20 15:29:53.574 [notice] Based on detected system memory, MaxMemInQueues is set to 739 MB. You can override this by setting MaxMemInQueues by hand.
Jul 20 15:29:53.576 [notice] Scheduler type KIST has been enabled.
Jul 20 15:29:53.576 [notice] Opening OR listener on 0.0.0.0:9001
Jul 20 15:29:53.576 [notice] Opening Extended OR listener on 127.0.0.1:0
Jul 20 15:29:53.577 [notice] Extended OR listener listening on port 40651.
Jul 20 15:29:54.000 [warn] Failed to open GEOIP file /usr/share/tor/geoip. We've been configured to see which countries can access us as a bridge, and we need GEOIP information to tell which countries clients are in. Do you have the tor-geoipdb package installed?
Jul 20 15:29:54.000 [warn] Failed to open GEOIP file /usr/share/tor/geoip6. We've been configured to see which countries can access us as a bridge, and we need GEOIP information to tell which countries clients are in. Do you have the tor-geoipdb package installed?
Jul 20 15:29:54.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Jul 20 15:29:54.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
Jul 20 15:29:56.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed E8094BFxxxxxxxxxx5C1E'
Jul 20 15:29:56.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'Unnamed BBAA6xxxxxxxxxAA811B'
Jul 20 15:29:56.000 [notice] Bootstrapped 0%: Starting
Jul 20 15:30:03.000 [notice] Starting with guard context "default"
Jul 20 15:30:03.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Jul 20 15:30:03.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Jul 20 15:30:04.000 [warn] Server managed proxy encountered a method error. (meek listen tcp 0.0.0.0:443: bind: address already in use)
Jul 20 15:30:04.000 [warn] Managed proxy at '/usr/local/bin/meek-server' failed the configuration protocol and will be destroyed.
Jul 20 15:30:04.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jul 20 15:30:06.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 20 15:30:06.000 [notice] Bootstrapped 100%: Done
Jul 20 15:30:06.000 [notice] Now checking whether ORPort 45.xxx.xxx.xxx:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jul 20 15:30:09.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 20 15:31:14.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 442 buildtimes.
Jul 20 15:31:20.000 [notice] Performing bandwidth self-test...done.
**And then it has no output and seems not working. Besides the above one, once I also got the output:**
...
Jul 20 08:24:27.000 [notice] Performing bandwidth self-test...done.
Jul 20 09:23:17.000 [notice] No circuits are opened. Relaxed timeout for circuit 30 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway.
**What's wrong with my steps in setting the meek server? What should I do next to set up a meek server, either for use or for test?
Must I use CDN to domain fronting it?**
By the way, is it possible to use meek without domain fronting if the domain has not been filtered?
May be I misunderstood something in https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-serverbridge and meek's README and I am sorry for that.
**Trac**:
**Username**: weiruoDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/27579Investigate usage of CDN77 for meek2021-11-08T19:49:21ZTracInvestigate usage of CDN77 for meekThe CDN Provider CDN77 supports origin pull and domain fronting. This may be useful if Microsoft Azure starts matching SNI with the Host header as Cloudflare, AWS, Google, etc have done.
**Confirmation:**
```
curl https://www.cdn77.com/...The CDN Provider CDN77 supports origin pull and domain fronting. This may be useful if Microsoft Azure starts matching SNI with the Host header as Cloudflare, AWS, Google, etc have done.
**Confirmation:**
```
curl https://www.cdn77.com/ --header 'Host: www.phpmyadmin.net' -v
```
**Trac**:
**Username**: nsuchyDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/28168Use ESNI via Firefox HTTPS helper2023-06-11T05:41:55ZDavid Fifielddcf@torproject.orgUse ESNI via Firefox HTTPS helperAs of 2018-10-18, [Firefox Nightly supports](https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/) encrypted SNI, and [Cloudflare supports it](https://blog.cloudflare.com/esni/) on the server side. Because...As of 2018-10-18, [Firefox Nightly supports](https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/) encrypted SNI, and [Cloudflare supports it](https://blog.cloudflare.com/esni/) on the server side. Because meek supports using Firefox as a channel for issuing HTTPS requests, it ought to be pretty easy to adapt the meek client software to use ESNI rather than domain fronting. The server software doesn't need any change.
These steps are untested:
1. Download Tor Browser and Firefox Nightly.
1. Go to about:config in Firefox Nightly and set
* network.trr.mode=3
* network.trr.uri=https<span>://</span>1.1.1.1/dns-query
* network.security.esni.enabled=true
1. Copy the meek-http-helper<span>@</span>bamsoftware.com.xpi from Tor Browser to Firefox Nightly.
1. Hack meek-client-torbrowser/{mac,linux,windows}.go to point `firefoxPath` at the copy of Firefox Nightly and disable the custom profile. (Additional hacks to remove hardcoded Tor Browser assumptions may be required.)
1. Set up a Cloudflare instance pointing to https<span>://</span>meek.bamsoftware.com/, call it https<span>://</span>meek.example.com/.
1. Set up a [custom bridge](/legacy/trac/-/wikis/doc/meek#how-to-change-the-front-domain) in Tor Browser, using `url=` without `front=` (because we're no longer domain fronting).
```
bridge meek 0.0.2.0:3 url=https://meek.example.com/
```
Of course, once ESNI support makes it into the version of Firefox used by Tor Browser, this will be even easier, not requiring a separate Firefox Nightly.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29077uTLS for meek-client camouflage2022-09-05T16:48:42ZDavid Fifielddcf@torproject.orguTLS for meek-client camouflageUse [utls](https://github.com/refraction-networking/utls) ([paper](https://censorbib.nymity.ch/#Frolov2019a)) for TLS camouflage instead of a headless Firefox helper. The camouflage will not be as robust as a headless browser, but the co...Use [utls](https://github.com/refraction-networking/utls) ([paper](https://censorbib.nymity.ch/#Frolov2019a)) for TLS camouflage instead of a headless Firefox helper. The camouflage will not be as robust as a headless browser, but the complexity will be lower. It will be portable to platforms that don't have a convenient Firefox instance to use. It will fix legacy/trac#12774, which is caused by tor starting multiple instances of meek-client-torbrowser, which in turn start multiple instances of Firefox, which error because they are using the same profile directory.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29171Redeploy meek-server instances with go1.11.52020-06-27T13:44:12ZDavid Fifielddcf@torproject.orgRedeploy meek-server instances with go1.11.5[CVE-2019-6486](https://github.com/golang/go/issues/29903) is a DoS on the implementation of certain elliptic curves, fixed in go1.11.5.
Redeploy servers that use crypto/tls and therefore may be exposed to the bug:
- [cymrubridge02](htt...[CVE-2019-6486](https://github.com/golang/go/issues/29903) is a DoS on the implementation of certain elliptic curves, fixed in go1.11.5.
Redeploy servers that use crypto/tls and therefore may be exposed to the bug:
- [cymrubridge02](https://metrics.torproject.org/rs.html#details/8F4541EEE3F2306B7B9FEF1795EC302F6B84DAE8) (backend for meek-azure)
- starman (throttled meek.bamsoftware.com)
- maenad (unthrottled meek.bamsoftware.com)
- GAEuploader (gaeuploader.meek.bamsoftware.com)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29347Rewrite meek-http-helper as a WebExtension2021-03-29T18:36:43ZDavid Fifielddcf@torproject.orgRewrite meek-http-helper as a WebExtensionFirefox 60 ESR (the current basis of Tor Browser 8) officially doesn't support "legacy" browser extensions using XPCOM/XUL, only the newer WebExtension API.
https://www.mozilla.org/en-US/firefox/60.0esr/releasenotes/#changed
Tor Browser ...Firefox 60 ESR (the current basis of Tor Browser 8) officially doesn't support "legacy" browser extensions using XPCOM/XUL, only the newer WebExtension API.
https://www.mozilla.org/en-US/firefox/60.0esr/releasenotes/#changed
Tor Browser still includes some legacy extensions; apparently what makes them keep working is a [extensions.legacy.exceptions](https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?id=4d0f9fa5fdd5831fbc2e28cb6c7b1056bd4deeab#n265) pref (legacy/trac#26127; thanks sukhe for knowing that). I don't see where !meek-http-helper@bamsoftware.com is being allowed (edit: probably a [comment:4 source patch], thanks mcs), but somehow it is still working too.
Assess whether it's possible to rewrite the helper as a WebExtension, and do it if so. Ideally it will be possible to keep 100% compatibility with the current helper interface; but changing meek-client and meek-client-torbrowser is also an option.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29364Tone down [WARN] log messages resulting from meek-client output2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgTone down [WARN] log messages resulting from meek-client outputSince legacy/trac#28179, tor logs any output from managed proxies' stderr at the WARN level. So meek-client's log messages like
```
2019/02/07 08:12:22 listening on 127.0.0.1:39071
```
that formerly went into a black hole, now get logged...Since legacy/trac#28179, tor logs any output from managed proxies' stderr at the WARN level. So meek-client's log messages like
```
2019/02/07 08:12:22 listening on 127.0.0.1:39071
```
that formerly went into a black hole, now get logged by tor as
```
2/7/19, 08:12:22.657 [WARN] Managed proxy at './TorBrowser/Tor/PluggableTransports/meek-client' reported: 2019/02/07 08:12:22 listening on 127.0.0.1:39071
```
The only real problem here is one of user interface. Being logged at WARN level causes the ⚠️ to pop up in Tor Launcher, when this is not something that requires user attention at all.
May affect other transports.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29525Allow proxy credentials in `meek-client --helper`2021-11-08T19:49:21ZDavid Fifielddcf@torproject.orgAllow proxy credentials in `meek-client --helper`meek-client [doesn't allow](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/meek-client.go?h=0.31#n362) a proxy username and password when using the browser helper. I think that at the time (circa Firefox 32)...meek-client [doesn't allow](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/meek-client.go?h=0.31#n362) a proxy username and password when using the browser helper. I think that at the time (circa Firefox 32) it wasn't supported using the API available to browser extensions.
But Firefox 45 [added credentials support](https://bugzilla.mozilla.org/show_bug.cgi?id=1200802) for SOCKS proxies, and while [it's not as straightforward for http/https proxies](https://bugzilla.mozilla.org/show_bug.cgi?id=1360404), apparently what you can do is set a [webRequest.onAuthRequired](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired) listener, and check inside it whether [details.isProxy](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired#details) is set (since Firefox 60-ish?).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29526Allow https proxies in `meek-client --helper`2021-11-08T19:49:22ZDavid Fifielddcf@torproject.orgAllow https proxies in `meek-client --helper`When using the browser helper, we currently allow http, socks4a, and socks5 proxies. [Since Firefox 33](https://bugzilla.mozilla.org/show_bug.cgi?id=378637), Firefox supports https proxies as well.When using the browser helper, we currently allow http, socks4a, and socks5 proxies. [Since Firefox 33](https://bugzilla.mozilla.org/show_bug.cgi?id=378637), Firefox supports https proxies as well.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29559meek-client-torbrowser should exit on stdin close, even while waiting on brow...2020-06-27T13:44:12ZDavid Fifielddcf@torproject.orgmeek-client-torbrowser should exit on stdin close, even while waiting on browser outputEdit the browser extension not to output the `meek-http-helper: listen` line, or hack meek-client-torbrowser to break `grepHelperAddress`. Start Tor Launcher, select meek, and Connect. Now Cancel and exit Tor Browser. The bug is that mee...Edit the browser extension not to output the `meek-http-helper: listen` line, or hack meek-client-torbrowser to break `grepHelperAddress`. Start Tor Launcher, select meek, and Connect. Now Cancel and exit Tor Browser. The bug is that meek-client-torbrowser and its child process firefox will continue running.
It happens because meek-client-torbrowser's `TOR_PT_EXIT_ON_STDIN_CLOSE` and SIGTERM logic happen only after `grepHelperAddr`. meek-client-torbrowser should pay attention to its stdin the whole time so that it can exit correctly in this case.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/29871Meek-Azure Pluggable Transport Not working2020-06-27T13:44:11ZTracMeek-Azure Pluggable Transport Not workingMeek-Azure pluggable transport is not working. Results in error- Establishing an encrypted directory connection failed. The problem has been replicated across several devices and several separate implementations of Tor across several ISP...Meek-Azure pluggable transport is not working. Results in error- Establishing an encrypted directory connection failed. The problem has been replicated across several devices and several separate implementations of Tor across several ISPs within the Untied States. Tor log file has been attached to this ticket.
**Trac**:
**Username**: bakertaylor28David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/30895meek-cloudflare: Tunnel via Cloudflare Argo.2020-06-27T13:44:11Zcypherpunksmeek-cloudflare: Tunnel via Cloudflare Argo.https://blog.cloudflare.com/a-free-argo-tunnel-for-your-next-project/https://blog.cloudflare.com/a-free-argo-tunnel-for-your-next-project/David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/31455Redeploy meek-server instances using Go 1.11.13+ / 1.12.8+2020-06-27T13:44:11ZDavid Fifielddcf@torproject.orgRedeploy meek-server instances using Go 1.11.13+ / 1.12.8+These versions fix a denial-of-service vulnerability in the HTTP/2 server code.
https://groups.google.com/d/msg/golang-announce/65QixT3tcmg/DrFiG6vvCwAJ
> We have just released Go 1.12.8 and Go 1.11.13 to address recently reported secur...These versions fix a denial-of-service vulnerability in the HTTP/2 server code.
https://groups.google.com/d/msg/golang-announce/65QixT3tcmg/DrFiG6vvCwAJ
> We have just released Go 1.12.8 and Go 1.11.13 to address recently reported security issues. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.12.8).
> * net/http: Denial of Service vulnerabilities in the HTTP/2 implementation
>
> net/http and golang.org/x/net/http2 servers that accept direct connections from untrusted clients could be remotely made to allocate an unlimited amount of memory, until the program crashes. Servers will now close connections if the send queue accumulates too many control messages.
>
> The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue [golang.org/issue/33606](https://golang.org/issue/33606).
>
> This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of golang.org/x/net/http2.
>
> * net/url: parsing validation issue
>
> url.Parse would accept URLs with malformed hosts, such that the Host field could have arbitrary suffixes that would appear in neither Hostname() nor Port(), allowing authorization bypasses in certain applications. Note that URLs with invalid, not numeric ports will now return an error from url.Parse.
>
> The issue is CVE-2019-14809 and Go issue [golang.org/issue/29098](https://golang.org/issue/29098).
We need to redeploy the following servers:
* ~~cymrubridge02 (backend for meek-azure, run by inf0)~~
* ~~BridgeDB Moat (run by sysrqb, phw)~~
* ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
* ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
* ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~Sina RabbaniSina Rabbanihttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/31890Redeploy meek-server instances using Go 1.12.10+ / 1.13.1+2020-06-27T13:44:11ZDavid Fifielddcf@torproject.orgRedeploy meek-server instances using Go 1.12.10+ / 1.13.1+https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases...https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases (if you’re not sure which, choose Go 1.13.1).
>
> net/http (through net/textproto) used to accept and normalize invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a Go server is used behind an uncommon reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or [request smuggling](https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn), the latter if requests from separate clients are multiplexed onto the same upstream connection by the proxy. Such invalid headers are now rejected by Go servers, and passed without normalization to Go client applications.
>
> The issue is CVE-2019-16276 and Go issue https://golang.org/issue/34540.
We need to redeploy the following servers:
* ~~cymrubridge02 (backend for meek-azure, run by inf0)~~
* ~~BridgeDB Moat (run by phw)~~
* ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
* ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
* ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~
The Moat configuration uses a reverse proxy, so this is perhaps relevant to us.Sina RabbaniSina Rabbanihttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/32037Tor Browser 8.5.5 Encounters Javascript problem when attempting to use Meek-...2020-06-27T13:44:11ZTracTor Browser 8.5.5 Encounters Javascript problem when attempting to use Meek-Azure bridgesI'm getting the following error when trying to use meek-azure in the logs. This looks to be a javascript problem of some sort or another that needs fixing.
```
[WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateproces...I'm getting the following error when trying to use meek-azure in the logs. This looks to be a javascript problem of some sort or another that needs fixing.
```
[WARN] Managed proxy at 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported: JavaScript error: jar:file:///C:/Scrubbed Path to Tor Installation Directory/Browser/TorBrowser/Data/Browser/profile.meek-http-helper/extensions/meek-http-helper@bamsoftware.com.xpi!/components/main.js, line 431: TypeError: invalid 'instanceof' operand Components.interfaces.nsIXPCException
```
**Trac**:
**Username**: bakertaylor28https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/40000Gitlab Migration Milestone2020-06-13T18:32:57ZTracGitlab Migration MilestoneWe're creating this ticket as a part of the Trac-to-Gitlab migration, so that each project's numbering for new tickets will start with 40001.We're creating this ticket as a part of the Trac-to-Gitlab migration, so that each project's numbering for new tickets will start with 40001.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/40001meek-azure and moat are down2021-06-10T14:12:25ZGusmeek-azure and moat are downWe received multiple reports that on frontdesk and social media that meek-azure and Moat are down.
Below an email with more details.
```
Both meek-azure and moat (used for fetching new obfs4 bridges from a censored location) are down. o...We received multiple reports that on frontdesk and social media that meek-azure and Moat are down.
Below an email with more details.
```
Both meek-azure and moat (used for fetching new obfs4 bridges from a censored location) are down. obfs4 works normally. Current location is the United States.
Unlike previous outages I've noticed, this one fails quickly and early into the connection attempt with a TLS error (instead of e.g. eventually timing out), suggesting a type of issue that hasn't occurred before.
Issue occurs on a fresh install of the latest version of Tor Browser for win32, win64, and Android (as well as Orbot). Windows (64-bit) log reproduced below, though it looks similar on all devices I've tried.
It doesn't look like this issue has been reported on GitLab yet. I've requested an account; currently awaiting approval.
12/5/20, 19:54:42.301 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/5/20, 19:54:42.301 [NOTICE] Opening Socks listener on 127.0.0.1:9150
12/5/20, 19:54:42.301 [NOTICE] Opened Socks listener on 127.0.0.1:9150
12/5/20, 19:54:45.298 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
12/5/20, 19:54:45.301 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
12/5/20, 19:54:45.306 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
12/5/20, 19:54:45.646 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (TLS_ERROR; TLS_ERROR; count 1; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CE at 0.0.2.0:2)
12/5/20, 19:54:45.647 [WARN] 1 connections have failed:
12/5/20, 19:54:45.647 [WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
12/5/20, 19:54:45.673 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
12/5/20, 19:54:45.674 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/5/20, 19:54:46.242 [WARN] Pluggable Transport process terminated with status code 0
```Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/40002meek-client tests failing2021-09-03T21:58:42Zmax-bmeek-client tests failingI think for one, it looks like [copyPublicFields](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/utls_test.go#n17) never got added and/or the `TestCopyPublicFieldsHTTPTransport` test is no longer necessary?
...I think for one, it looks like [copyPublicFields](https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/utls_test.go#n17) never got added and/or the `TestCopyPublicFieldsHTTPTransport` test is no longer necessary?
Additionally, the `TestProxyHTTPSCONNECT` seems to be failing with this output:
```
❯ go test . -v
=== RUN TestMakeProxySpec
--- PASS: TestMakeProxySpec (0.00s)
=== RUN TestAddrForDial
--- PASS: TestAddrForDial (0.00s)
=== RUN TestProxyHTTPCONNECT
--- PASS: TestProxyHTTPCONNECT (0.00s)
=== RUN TestProxyHTTPProxyAuthorization
--- PASS: TestProxyHTTPProxyAuthorization (0.00s)
=== RUN TestProxyHTTPSCONNECT
proxy_test.go:95: local error: tls: unexpected message
--- FAIL: TestProxyHTTPSCONNECT (0.01s)
panic: remote error: tls: unexpected message [recovered]
panic: remote error: tls: unexpected message
goroutine 18 [running]:
testing.tRunner.func1.2(0x7d9200, 0xc0000203c0)
/usr/local/go/src/testing/testing.go:1144 +0x332
testing.tRunner.func1(0xc00008a300)
/usr/local/go/src/testing/testing.go:1147 +0x4b6
panic(0x7d9200, 0xc0000203c0)
/usr/local/go/src/runtime/panic.go:965 +0x1b9
git.torproject.org/pluggable-transports/meek.git/meek-client.TestProxyHTTPSCONNECT(0xc00008a300)
/home/maxb/work/tor/meek/meek-client/proxy_test.go:232 +0x3ec
testing.tRunner(0xc00008a300, 0x847030)
/usr/local/go/src/testing/testing.go:1194 +0xef
created by testing.(*T).Run
/usr/local/go/src/testing/testing.go:1239 +0x2b3
FAIL git.torproject.org/pluggable-transports/meek.git/meek-client 0.021s
FAIL
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/40003Support a user-chosen --bind address and port in meek-client2021-12-27T20:58:44Zmig5Support a user-chosen --bind address and port in meek-clientHi,
Right now, meek-client hardcodes 127.0.0.1:0 in its call to net.Listen, resulting in a random port being chosen each time meek-client starts.
Over at the OnionShare project we have started subprocessing meek-client in order to do d...Hi,
Right now, meek-client hardcodes 127.0.0.1:0 in its call to net.Listen, resulting in a random port being chosen each time meek-client starts.
Over at the OnionShare project we have started subprocessing meek-client in order to do domain-fronting to the BridgeDB as well as the Censorship Circumvention API as part of the S96 work.
We have had to resort to crazy hacks to parse the random port from the stdout of the meek-client subprocess in order to use it as a proxy in our HTTP requests.
It would be a lot nicer if it supported a flag to send a user-chosen address/port. That way we can choose our own random port from an existing method we have for such things, and no more parsing the stdout..
I couldn't work out where to send a pull request for https://gitweb.torproject.org/pluggable-transports/meek.git/ - can anyone help me out?
Otherwise the patch is below.
Thanks!
```
commit 45ea1bd6abaf96c1dcf6f02e72dc4eeda7428564 (HEAD -> support-user-chosen-bind-address)
Author: Miguel Jacq <mig@mig5.net>
Date: Thu Dec 23 17:43:09 2021 +1100
Support optional --bind flag to bind to a user-chosen address and port
diff --git a/meek-client/meek-client.go b/meek-client/meek-client.go
index 3431b53..133d210 100644
--- a/meek-client/meek-client.go
+++ b/meek-client/meek-client.go
@@ -97,6 +97,7 @@ var options struct {
ProxyURL *url.URL
UseHelper bool
UTLSName string
+ BindAddr string
}
// RequestInfo encapsulates all the configuration used for a request–response
@@ -407,6 +408,7 @@ func main() {
flag.StringVar(&options.Front, "front", "", "front domain name if no front= SOCKS arg")
flag.StringVar(&helperAddr, "helper", "", "address of HTTP helper (browser extension)")
+ flag.StringVar(&options.BindAddr, "bind", "", "address to bind on (default: 127.0.0.1:0 where port 0 will be randomly chosen)")
flag.StringVar(&logFilename, "log", "", "name of log file")
flag.StringVar(&proxy, "proxy", "", "proxy URL")
flag.StringVar(&options.URL, "url", "", "URL to request if no url= SOCKS arg")
@@ -447,6 +449,11 @@ func main() {
}
}
+ // If no bind address was set, use a random port on localhost
+ if options.BindAddr == "" {
+ options.BindAddr = "127.0.0.1:0"
+ }
+
// Disable the default ProxyFromEnvironment setting.
// httpRoundTripper.Proxy is overridden below if options.ProxyURL is
// set.
@@ -481,7 +488,7 @@ func main() {
for _, methodName := range ptInfo.MethodNames {
switch methodName {
case ptMethodName:
- ln, err := pt.ListenSocks("tcp", "127.0.0.1:0")
+ ln, err := pt.ListenSocks("tcp", options.BindAddr)
if err != nil {
pt.CmethodError(methodName, err.Error())
break
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues/40004Missing some commits after gitlab migration2024-03-18T07:54:47ZCecylia BocovichMissing some commits after gitlab migrationI was debugging a meek server setup and noticed that the meek repository I had checked out from before the gitlab migration has a git history inconsistent with the repository on Gitlab.
On my machine:
```
commit 46e612d2e9afd6e5dfa54c47...I was debugging a meek server setup and noticed that the meek repository I had checked out from before the gitlab migration has a git history inconsistent with the repository on Gitlab.
On my machine:
```
commit 46e612d2e9afd6e5dfa54c473ed17aeab49001af (HEAD -> main)
Author: David Fifield <david@bamsoftware.com>
Date: Wed Dec 29 22:06:41 2021 -0700
Fix the locking around rt.rt.
sync.Once does not prevent other goroutines from accessing a variable
that has not been defined yet.
commit 88fd7233036450e0d3278f3afe0a9995974ae120
Author: David Fifield <david@bamsoftware.com>
Date: Wed Dec 29 21:35:06 2021 -0700
Only lock the assignment to rt.rt, not the whole RoundTrip.
We need to guard against concurrent modification of rt.rt, but once it
is set, we many concurrently call rt.rt.RoundTrip. The way this was
written before, it was preventing more than one RoundTrip from happening
at once. (Which was not noticeable, because the protocol serialized all
RoundTrips.)
commit 6600c52acb7979b08dd0916a7a779dd0e5dde0b0
Author: David Fifield <david@bamsoftware.com>
Date: Tue Sep 14 13:22:10 2021 -0600
Add missing transport to ServerTransportListenAddr in meek-server man page.
```
On Gitlab:
```
commit e195aff85633786ee4b8f175cb7a2ec8ee12952b (HEAD -> main, origin/main, origin/HEAD)
Author: meskio <meskio@torproject.org>
Date: Tue Apr 18 19:04:02 2023 +0200
Add CI
commit 048441a54233c0e64bd3f9821b2cc9f8a36f5aea
Author: meskio <meskio@torproject.org>
Date: Tue Apr 18 18:52:29 2023 +0200
Move the project to gitlab
commit cb192ff42a3662b6cbbfc901114c499366c7b8a0
Author: meskio <meskio@torproject.org>
Date: Tue Apr 18 17:49:11 2023 +0200
Use goptlib from gitlab
Related: tpo/anti-censorship/team/-/issues/86
commit 6600c52acb7979b08dd0916a7a779dd0e5dde0b0
Author: David Fifield <david@bamsoftware.com>
Date: Tue Sep 14 13:22:10 2021 -0600
Add missing transport to ServerTransportListenAddr in meek-server man page.
```
Did something happen with the migration that resulted in some commits getting dropped?