meek issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/meek/-/issues2024-03-18T07:54:47Zhttps://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?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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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.org