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