[tor-bugs] #8860 [Archived/Flashproxy]: Registration over App Engine

[Tor Bug Tracker & Wiki]

#8860: Registration over App Engine
---------------------------------+------------------------
 Reporter:  dcf                  |          Owner:  dcf
     Type:  project              |         Status:  closed
 Priority:  High                 |      Milestone:
Component:  Archived/Flashproxy  |        Version:
 Severity:  Normal               |     Resolution:  fixed
 Keywords:                       |  Actual Points:
Parent ID:                       |         Points:
 Reviewer:                       |        Sponsor:
---------------------------------+------------------------
Changes (by dcf):

 * severity:   => Normal


Old description:

> It apparently is possible to use
> [https://en.wikipedia.org/wiki/Google_App_Engine Google App Engine] apps
> if you can access https:‍//www.google.com/. We can use this for
> rendezvous.
>
> As an example of doing it manually, you can run
> [https://lists.torproject.org/pipermail/tor-talk/2013-April/027788.html
> flashproxy-reg-url] and paste the URL you get into an existing proxy app
> like https://g-proxy.appspot.com/ or https://bingproxy.appspot.com/, and
> that is sufficient for rendezvous.
>
> One way of doing it automatically with a custom App Engine app is to have
> the app figure out the client's IP address from the request, and insert
> it along with the client's given port number in a new registration to the
> facilitator. (This is pretty much what
> [https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a
> :/flashproxy-reg-http flashproxy-reg-http] and
> [https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a:/facilitator/facilitator.cgi#l30
> facilitator.cgi] do now, except it's like having facilitator.cgi run on a
> different host than the facilitator.) The downside of this approach is
> that the IP:port information becomes known to the app and to Google.
> (Though we can't hide the IP anyway, because it's part of the HTTP
> request to the app.)
>
> A better way would be to have the app forward encrypted registration
> blobs, like Gmail does with the [#6383 email rendezvous]. The problem
> here is that the client needs to know its own IP address. I propose
> having the App Engine app interpret requests for `/ip` as a request for
> the requestor's IP address. It should return the IP address as a
> text/plain document in a single line. The other path pattern understood
> by the app will be `/reg/<blob>`, which it will simply forward by making
> a new HTTP request for https:‍//fp-facilitator.org/<blob>.
>
> Two parts to this project:
>  1. App Engine app handling `/ip` and `/reg' as above.
>  2. A client program `flashproxy-reg-appspot`. The client program makes a
> request for `/ip` to find out its IP, then generates a base64 blob from
> the IP and port, the same way `flashproxy-reg-url` does. It then makes a
> second request to `/reg/<blob>` to effect the registration. The App
> Engine app does nothing but a URL fetch of https:‍//fp-
> facilitator.org/reg/<blob>. The client program should have `-4` and `-6`
> options.

New description:

 It apparently is possible to use
 [https://en.wikipedia.org/wiki/Google_App_Engine Google App Engine] apps
 if you can access !https://www.google.com/. We can use this for
 rendezvous.

 As an example of doing it manually, you can run
 [https://lists.torproject.org/pipermail/tor-talk/2013-April/027788.html
 flashproxy-reg-url] and paste the URL you get into an existing proxy app
 like https://g-proxy.appspot.com/ or https://bingproxy.appspot.com/, and
 that is sufficient for rendezvous.

 One way of doing it automatically with a custom App Engine app is to have
 the app figure out the client's IP address from the request, and insert it
 along with the client's given port number in a new registration to the
 facilitator. (This is pretty much what
 [https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a
 :/flashproxy-reg-http flashproxy-reg-http] and
 [https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a:/facilitator/facilitator.cgi#l30
 facilitator.cgi] do now, except it's like having facilitator.cgi run on a
 different host than the facilitator.) The downside of this approach is
 that the IP:port information becomes known to the app and to Google.
 (Though we can't hide the IP anyway, because it's part of the HTTP request
 to the app.)

 A better way would be to have the app forward encrypted registration
 blobs, like Gmail does with the [#6383 email rendezvous]. The problem here
 is that the client needs to know its own IP address. I propose having the
 App Engine app interpret requests for `/ip` as a request for the
 requestor's IP address. It should return the IP address as a text/plain
 document in a single line. The other path pattern understood by the app
 will be `/reg/<blob>`, which it will simply forward by making a new HTTP
 request for https:‍//fp-facilitator.org/<blob>.

 Two parts to this project:
  1. App Engine app handling `/ip` and `/reg' as above.
  2. A client program `flashproxy-reg-appspot`. The client program makes a
 request for `/ip` to find out its IP, then generates a base64 blob from
 the IP and port, the same way `flashproxy-reg-url` does. It then makes a
 second request to `/reg/<blob>` to effect the registration. The App Engine
 app does nothing but a URL fetch of https:‍//fp-
 facilitator.org/reg/<blob>. The client program should have `-4` and `-6`
 options.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8860#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online