meek issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues2021-11-08T19:49:22Zhttps://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/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/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/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/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/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/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/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/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/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/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.org