Судя по описанию, у Moat дистрибьютера нет возможности получить адрес клиента, передаваемый CDN. Meek сервер отбросит эти данные.

or, err := pt.DialOr(&ptInfo, getUseraddr(req), ptMethodName)

// Dial info.ExtendedOrAddr if defined, or else info.OrAddr, and return an open
// *net.TCPConn. If connecting to the extended OR port, extended OR port
// authentication à la 217-ext-orport-auth.txt is done before returning; an
// error is returned if authentication fails.
//
// The addr and methodName arguments are put in USERADDR and TRANSPORT ExtOrPort
// commands, respectively. If either is "", the corresponding command is not
// sent.
func DialOr(info *ServerInfo, addr, methodName string) (*net.TCPConn, error) {
	if info.ExtendedOrAddr == nil || info.AuthCookiePath == "" {
		return net.DialTCP("tcp", nil, info.OrAddr)
	}

	s, err := net.DialTCP("tcp", nil, info.ExtendedOrAddr)
	if err != nil {
		return nil, err
	}
	err = extOrPortSetup(s, 5*time.Second, info, addr, methodName)
	if err != nil {
		s.Close()
		return nil, err
	}

	return s, nil
}

Для получения адреса нужно настроить TOR_PT_EXTENDED_SERVER_PORT для Meek сервера и уметь в ExtOrPort commands на стороне Moat дистрибьютера.

Описание не отражает работоспособную конфигурацию? Или для Moat действительно все клиенты неразличимы?

Что пропущено?

That is an astute question. I think the documentation on the Moat wiki page is simply out of date. In fact TOR_PT_EXTENDED_SERVER_PORT is set and there is a special “shim” component that interprets the ExtORPort commands and converts them into an X-Forwarded-For header so the web server can know the client’s IP address.

This is the main development discussion:

In short, there are two layers of HTTPS in Moat: an outer layer with the CDN (for blocking resistance) and an inner end-to-end layer with the BridgeDB (for confidentiality and integrity, so the CDN cannot tamper with BridgeDB responses). The CDN adds an X-Forwarded-For header (this is a standard feature of CDNs). meek-server receives and decrypts this outer layer, so meek-server knows the client IP address. meek-server dials the ExtORPort of moat-shim (in the README here you can see TOR_PT_EXTENDED_SERVER_PORT being set) and sends the client IP address as USERADDR. moat-shim decrypts the inner HTTPS layer that has been de-serialized by meek-server, and re-adds the client IP address as an X-Forwarded-For header before forwarding plain HTTP to the BridgeDB Apache.

Thank you!

Есть такая точка зрения на сбор адресов бриджей.

It looks like in the real world this protection hasn’t stopped big attackers from listing all the bridges, and the effort might not be worth it.

Но Moat (в отличии от HTTPS) делает сбор совсем простым. Можно подключаться напрямую к Meek серверу (/meek), Moat дистрибьютеру (/moat) с ложными заголовками Meek-IP (изображая CDN), X-Forwarded-For (изображая moat-shim).

Возможно ТСПУ действительно big attacker, но что если они просто читеры?

Небольшой скрипт (Moat клиент) для проверки возможности собрать “китайские” бриджи из москвы.
https://paste.debian.net/plainh/a8658889
Это работает.

Если вы это делаете для использования бриджей по прямому назначению, то гораздо проще, удобней и надёжней использовать обычные relay’и в качестве бриджей. На сегодняшний день более 1400 релеев остаются доступными на провайдерах с ТСПУ, и их либо не так активно блокируют, либо не блокируют вовсе.

Вот вам 10 случайных рабочих relay’ев:

Bridge 160.119.249.24:443 801EF80845848E685C4534A2408D32D5443187DF
Bridge 139.162.161.211:12355 6ACD584F2FAA75D95ECCF54CA504422BAE78A549
Bridge 43.251.170.52:443 49000EA5D4368F7F3943425F06AE86F3DF2CCF42
Bridge 109.70.100.67:443 A4F0F516C83DE11B290384B9B4A4C928A78ED3A5
Bridge 144.76.108.49:9001 76BAB224055F8532288685BEA93F249FCEF05BF9
Bridge 45.15.16.207:9001 A377E632580AE4A20E447E5DA153AAEC346DA20A
Bridge 70.120.126.172:443 BF3E9B97D3CE4099F73AA4BD70CA14B635FA3CEA
Bridge 91.150.101.29:9001 4BA47DC1C3C1778CC78DDD4E33036DB98CC421E9
Bridge 91.67.169.183:9001 3DD8B251728B1C284DFB0FD169BA07400FFCA0FA
Bridge 218.41.17.40:9001 7173FDE91FFA2415DDD96FDB5C318405B287BB41

But Moat (as opposed to HTTPS) makes gathering quite simple. You can connect directly to a Meek server (/meek), a Moat distributor (/moat) with false headers Meek-IP (impersonating CDN), X-Forwarded-For (impersonating moat-shim).

Hmm, you may be right. If a request reaches the /meek endpoint after being forwarded through /moat, it will have a trustworthy X-Forwarded-For, but not necessarily if a connection arrives directly to the /meek endpoint. I have opened an issue for this.

-x socks5h://127.0.0.1:9150

If the system is working correctly, I think this strategy will get only a subset of available bridges. BridgeDB has different “bridgerings” or “hashrings” of available bridges. All requests that come from a Tor exit or from another known proxy are supposed to be limited to a subset of the available bridges. See for example:

:param proxies: A :class:`bridgedb.proxy.ProxySet` containing known
    Tor Exit relays and other known proxies.  These will constitute
    the extra cluster, and any client requesting bridges from one of
    these **proxies** will be distributed bridges from a separate
    subhashring that is specific to Tor/proxy users.

But I don’t know how well this defense really works in practice.

There was another problem with BridgeDB/Moat, which is that there were only a few (10K) static captchas, and they had not been regenerated in a long time. An adversary may have been simply reusing known answers to solved captchas. The captchas have recently been regenerated and there are more of them now.

https://lists.torproject.org/pipermail/anti-censorship-team/2021-December/000208.html

Это хорошо и для тестов этого достаточно, поскольку это подмножество тоже делится на подсети.

some spikes in Moat

Было бы интересно сравнить эти цифры со статистикой запросов к CDN.

2021-11-16,moat,66900

2021-11-15,moat,22870
2021-11-16,moat,66900

2022-01-10,moat,57345
2022-01-11,moat,98775
2022-01-12,moat,98235

Рота курсантов работает cо вторника. По ~40К запросов. Стабильность.