[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 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.

 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
   }}}
 (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.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24432#comment:35>
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