[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly
#24432: The meek<->moat tunneling isn't set up correctly
----------------------------------+--------------------------
Reporter: isis | Owner: isis
Type: defect | Status: closed
Priority: High | Milestone:
Component: Obfuscation/BridgeDB | Version:
Severity: Normal | Resolution: fixed
Keywords: moat bridgedb-dist | Actual Points:
Parent ID: #24689 | Points: 2
Reviewer: | Sponsor: SponsorM
----------------------------------+--------------------------
Comment (by isis):
Replying to [comment:35 dcf]:
> Replying to [comment:28 isis]:
> > 2. Either the meek-reflector or the meek-server or the Apache server
is changing the `X-Forwarded-For` header from `"X-Forwarded-For: 1.2.3.4"`
to `"X-Forwarded-For: 1.2.3.4, 127.0.0.1"`. This is unfortunate, as it
means that we're not able to get accurate IP information about the client
to use for anti-scraping protections (also it bungles the security of the
CAPTCHAs because it also means clients can "trade" CAPTCHAs and
solutions). There is a temporary "fix" for this in my `fix/24432-ignore-
loopback` branch, which simply skips loopback addresses while parsing the
`X-Forwarded-For` headers. Eventually we'll need to find which piece of
infrastructure is setting the IP to 127.0.0.1 and change it to report the
client's actual IP, then disable this fix (there's a config option). :/
>
> I'm pretty sure it's Apache adding the extra `X-Forwarded-For:
127.0.0.1` (through the `ProxyPass` directive).
>
> As for getting the remote client address, you will have to
[https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-
server/useraddr.go?h=0.28 do what meek-server does]:
> 1. Use the contents of the `Meek-IP` header, if it exists.
> 2. Otherwise, use the first entry of `X-Forwarded-For`, if it exists.
> 3. Otherwise, give up or use the connection's source IP address.
> The reason you have to check `Meek-IP` is that App Engine
[https://gitweb.torproject.org/pluggable-
transports/meek.git/tree/appengine/reflect.go?h=0.28#n77 doesn't set X
-Forwarded-For], and doesn't allow applications to set it. Other CDNs set
`X-Forwarded-For` automatically. See #13171.
Oh thanks! I had no idea about the `Meek-IP` header.
> I don't think you need special logic for loopback addresses in `x
-Forwarded-For`: just take the first entry.
[https://en.wikipedia.org/wiki/X-Forwarded-For#Format According to
Wikipedia], the client's address is the first entry, not the last:
> {{{
> X-Forwarded-For: client, proxy1, proxy2
> }}}
BridgeDB's logic (not my code) does exactly the opposite (without any
comment or explanation as to why). I've never fully understood why, but I
assumed it's because it was designed to run only behind the Apache server,
which is trusted. So the patch I made to make that code compatible also
with this new setup—when given a flag to ignore loopback addresses—will
parse `X-Forwarded-For: 2.2.2.2, 1.2.3.4, 127.0.0.1, 127.0.0.8` into
`1.2.3.4`. I ''think'' this is probably the most sane thing to do for now.
I'll go take a took if there's a `Meek-IP` header being sent, and then we
can just use that.
> (Hmm, but we should worry about `X-Forwarded-For` spoofing by clients—in
any case, `Meek-IP` will be trustworthy whenever it exists, because
reflect.go [https://gitweb.torproject.org/pluggable-
transports/meek.git/tree/appengine/reflect.go?h=0.28#n35 whitelists] which
headers it will forward and sets `Meek-IP` itself.)
Yeah, specifically the part I am worried about is that the `1.2.3.4` only
ended up in the header because I told curl to put it there… and other than
that we have no accurate IP for the client. So right now we're just going
on whatever they are saying.
I forgot to mention that I did a temporary config workaround "fix" to try
to diminish the effect this has, by setting `MOAT_N_IP_CLUSTERS` to `1`
(instead of `4`). This has the effect that there are two "clusters" of
client IPs: those who are using Tor/proxies, and those who aren't. If I
kept it at `4`, then everyone (who is not using Tor/proxies) could get
four times as many bridges per period as they are supposed to, simply by
lying four times (so an average of sixteen tries if they choose IPs
randomly, but still).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24432#comment:36>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs