[tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#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